(Archived) [FR] Links to specific notes and editing...

[vogelap 27]

([FR] == Feature Request, by the way)

I had a bad night last night. I couldn't get my mind to turn off to let me get to sleep... In an effort to get the things out of my mind and onto "trusted storage" lest I forget, I ended up with three (small) pages of handwritten notes about things going on in my professional and personal life, a couple additional notes scribbled on the back of my left hand, and two Post-It Notes with even more additional notes.

The weird thing is this... My PDA/Smartphone (with Evernote 3 for Windows Mobile ("EN3WM") on it) sits right next to my bed but I didn't use it at all for my note capturing. This morning, I've been thinking about WHY I didn't use Evernote 3 instead of paper, and I think I've come up with a couple reasons...

* I cannot edit an existing note in EN3WM. I've got a TO-DO list already in Evernote 3, but I cannot add/remove items from it via the EN3WM interface.

* I cannot edit the state of checklist items via EN3WM (I mean adding or removing checkboxes or changing their state). I understand that, technically, this is a subset of the item above, but it bears specific mention, I think.

* I don't want my TO-DO items in separate notes. I have a master TO-DO list and want to have only ONE.

* It would take me several clicks to get into a note via EN3WM if the notes were editable, which interferes with the immediacy (and fleeting nature) of my late-night brainstorms -- I want as few distractions/delays as possible when capturing ideas.

To that end, I've come up with a couple feature requests that I hope will be considered...

* Allow editing of existing notes via EN3WM.

* Allow management of checklist items (adding/removing checkboxes or changing their state) via EN3WM.

* I would like to have an icon on my PDA's today screen that a> linked me directly to a specific note (in my example, viewing my master TO-DO list), and another icon on my PDA's today screen that linked me directly to the EDITOR for a specific note (in my example, editing my master TO-DO list). This way, I could refer to my TO-DO list (or any other note(s) I'd selected) or EDIT a specific note VERY QUICKLY -- while the idea is fresh in my head.

I hope these Feature Requests make sense and are compelling enough that they will be considered for implementation!

[engberg 89]

Thanks for the feedback. We haven't implemented "edit existing note" on the mobile (yet) due to the issues involved with editing rich text notes that contain content which can't be rendered in a mobile editor ... e.g. formatting, images, etc. We didn't want to have people try to edit a complicated note and have it turned into a simple text document when they save. We explored some options (e.g. "can only edit notes that were created via mobile", "can only edit notes if we check them and confirm that they only have text"), but all of these introduced some ugly inconsistencies for users. ("Why do I get an 'edit' button on this note, but not this other one?") So we're still trying to figure out the right solution, given the capabilities of the devices.

[vogelap 27]

Thanks for your info! I appreciate hearing that these feature requests are on the radar.

[crashing_sux 0]

What about doing a simple text diff, then injecting the text into the rich text document. On the mobile device it will look just fine, plain text. In any other editor it will maintain it's formatting, and look reasonable, if not exactly what you want, but then it will be easy to alter the formatting there, where you care about it.

Say I have a header, 14 point bold.

Then a couple of lines below it, 10 point regular

Then maybe a bulleted list.

What are my worst case outcomes of this solution? I meant for something to be 10 point, but it was entered immedately following the header so it ended up bold in my windows/apple full client? Big deal, I highlight the text and change the font.

Something gets appended to the last item in the bulleted list instead of getting it's own bullet? Again, is this really a problem? If I really care, next time I look at that note I just move the text onto the next line and give it a bullet.

I'm a software developer myself and can understand the pressure to either implement a perfect solution, or leave it alone until you can think of a perfect solution but an agile/iterative approach could work well here. Give users an option that will work 95% of the time (do most users actually spend time formatting their notes, or do they just type/paste into a note and leave it alone?) and then refine the option if needed in the future. I'm going out on a limb here but I would guess that if you put up a poll giving two options to your users:

1. Notes are not editable on mobile clients, but you never have to worry about messing up their formatting.

2. Notes are editable on mobile clients, formatting will be taken from the text immediately preceding what you are editing (in other words, we just stuff plain text into the rtf doc with no formatting tags), and if you don't like the format you can either stop editing in the mobile client or manually modify the format next time you have access to a full featured client.

I would think most users would be happier with option 2.

Maybe you should throw up a poll?

-Shane

[engberg 89]

If the mobile device was only used for adding text, this would be pretty straightforward, although the results would be frequently goofy (e.g. trying to add text to an HTML document with a table in it ... the resulting text could go into some odd places you didn't expect, either inside or outside of cells that you couldn't see on the mobile.)

The bigger problem comes with changing/deleting some of the text. How to reconcile all of the markup and embedded content that isn't visible inside the plaintext editor. Trying to do a fully correct "diff" and "merge" on an HTML doc and a Text doc is not straightforward.

Essentially, we'd like to make sure that people can see & understand what the final results of their actions are, so that they aren't surprised to see that their icons have disappeared, etc. I.e. trying to follow the general Principle of Least Astonishment:

http://en.wikipedia.org/wiki/Principle_ ... tonishment

Currently, the mobile feature set may feel incomplete, but none of the actions should be surprising/irritating ... they work like you'd expect with no side effects, but you want more features.

[crashing_sux 0]

Hmmm.....good points. Although you may find quite a few users astonished/irritated that they can't edit a note on their mobile device. I was going off the example of the rtf and plain text you mentioned but now that I think about it, what are the actual limitations? What format is the windows editor using ? What format can the mobile client support?

Maybe the least astonishing route is to not allow deletions of parts of a complex not on the mobile editor, but additions and strikethrough?

A user could draw a line through the portion they want to delete, then add new text below. Back in the full editor they could then properly delete the strikethrough text if they want. It would get around most of the formatting issues that come to mind, although I haven't seen the mobile client first hand to know what the capabilities are. Even if the best you could do is make additions to a note (notes on notes in effect) it would be enough to solve the dual needs I am hearing, allow capture immediately, allow a nice format on the full client later.

I would argue that adding a note in my mobile client, then not being able to edit it immediately after (is that really the behavior?) would be astonishing to me. Maybe you only allow me to edit notes that were created in the mobile client. Maybe you warn me that I will lose all formatting (seems to work well enough in office when saving in older formats) or maybe you allow me to edit all notes, but only the non-complex sections. I actually like the last idea best.

It seems to me that you are saying since 5% of notes have complex features like HTML tables, no notes are editable in the mobile client. What would make more sense is to have complex objects locked. Users could edit the easy stuff and if they wanted to make a change to a table that the mobile client couldn't handle they would see it as read only, but could at least type write below it "Correct spelling of efficeint to efficient in table above" and then make the corrections later.

I don't think users would be astonished that their mobile client would not support the full clients formatting, but I would think they would be astonished that they could not at least capture their thoughts in an appropriate place (vs making a new note).

[vogelap 27]

Although you may find quite a few users astonished/irritated that they can't edit a note on their mobile device.

<raises hand>

[engberg 89]

There's a bit of a difference between "astonished" and "disappointed". My friend is disappointed that his car's GPS won't let him set a destination while he is in motion. He would be astonished if setting his GPS would occasionally open the trunk.

We're definitely working to reduce disappointment in our feature set (and increase the opposite ... would that be "appointment"?).

However, it's critical that we avoid astonishing situations where the user might say "Holy #*&$! I would never have predicted the trunk would open when I used the GPS" or "I just deleted & replaced a phone number in this note and now the table's broken and I've lost my ToDo checkmark and photo!"

I'm not invalidating your requests, just explaining the considerations that we've gone through which might prevent us from rushing this out prematurely.

Thanks

[crashing_sux 0]

There is quite a difference, but I think astonished is the correct term for the situation I described.

I think it's fair to say "Holy *****, I never would have predicted I could create a note, spell something wrong, and not be able to edit it 30 seconds later". As I've mentioned before, I haven't used the mobile app, so if this is not the behavior that currently exists, just let me know, I'm just trying to figure it out from the conversation.

The scenario you mention "I just deleted & replaced a phone number in this note and now the table's broken and I've lost my ToDo checkmark and photo!" is precisely why it would make sense to lock objects that are too complex for the mobile editor, or if that is too much work, to only lock notes that are too complex.

If it really is the case that a user can create a note on a mobile device (which by definition has no content a mobile device can't edit) and then the user is not allowed to edit it this would have nothing to do with the least astonishment principle, it would be a case of "You can't please all of the people all of the time, so why bother trying". I'm not trying to put words in your mouth, and I may be misunderstanding you but from what I am reading I heard a user mention a simple case "Why I don't use evernote mobile to capture a not at night, because I can't edit it." and the response is "Another user may try to edit a note he created using a different client, so we're going to make sure nobody can use this functionality in any scenario until we can support it perfectly".

This is a beta period, users would probably be understanding and grateful if the next release had even the simplest attempt at making this more workable, such as tagging notes when they are touched by any non-mobile editor, and allowing them to be edited on the mobile device up until the point they are modified in another editor. That really is a simple solution that satisfies the common scenario of not getting it quite right the first time and needing to fix it a minute later. Going back and editing it a day later is a different use case IMHO.

Now if it's not high up on the priority list I can understand that, lots to do I'm sure, but if you're trying to convince me that any feature you don't expect is astonishing and any feature I don't expect is merely disappointing then I would say we'll have to agree to disagree on this one. It comes down to user expectations. Users base their expectations based on their experiences. An email app without mouse interaction would not have been astonishing in the green screen days, but in the modern gui world it would be astonishing. Since I cannot think of any other tool I have used that allows me to create a note, then not edit/fix a typo, I would find it astonishing. Not EverNote Mobile lost my note, I'll never use it again, merely EverNote Mobile punishes me for not being perfect and getting it right the first time. Since I will never be perfect and stop needing to correct myself, I'll never use it again. Outcomes wise they don't seem that far apart, and I don't think anyone is making the case for saying that the mobile version should be allowed to mistakenly delete information, only have some (not a perfect) form of editing, especially notes that were just created on the mobile device.

[crashing_sux 0]

There's a bit of a difference between "astonished" and "disappointed". My friend is disappointed that his car's GPS won't let him set a destination while he is in motion. He would be astonished if setting his GPS would occasionally open the trunk.

We're definitely working to reduce disappointment in our feature set (and increase the opposite ... would that be "appointment"?).

However, it's critical that we avoid astonishing situations where the user might say "Holy #*&$! I would never have predicted the trunk would open when I used the GPS" or "I just deleted & replaced a phone number in this note and now the table's broken and I've lost my ToDo checkmark and photo!"

I'm not invalidating your requests, just explaining the considerations that we've gone through which might prevent us from rushing this out prematurely.

Thanks

While I didn't mention it specifically, yes I agree completely, any loss of data will cause a loss of trust that may not be repairable. I'm not advocating rushing anything out, just releasing the functionality in stages possibly. When you have a tough problem to solve it's worth tackling, if it were easy everyone would have solved it, but when that problem is an edge case it can be worth fixing it in the highest priority use case (while protecting against data loss in the unsolved uses) and continuing to work on the more complex aspects over the following months. I don't see it as an all or nothing situation.

It won't be solved tomorrow, but it's not exactly an intractable problem either.