UX: Open discussion on usability regarding how to handle the multitude of actions on headers

[aspiers]

[This previously arose as discussion in #153 and #169; splitting out into its own issue for clarity.]

Tapping a header causes the toolbar to appear which allows editing the header, contents, deadline etc. However because this toolbar appears above the selected header, it causes the header to shift vertically down, and then back up again if a different header further down is selected. (The latter would also happen in the future if deselection of the header is ever implemented as per #152.)

In #153, @munen commented on December 25, 2019 9:08 AM:

This is a recent change. Before, the action bar was below the header. Meaning, it was in between the header and its content. People rightfully complained that the action bar was now in the way in between related content. Hence, we moved it on top of the header. A few weeks later, you come along^^

I believe the issue tracking that change was #100. I agree with the referenced concerns from EmacsConf which it was trying to address; however I'm not at all convinced that the change implemented was the right one, and it seems I'm not the only one. Going back to #153, @schoettl replied on December 26, 2019 9:42 AM:

To be honest, I also liked it better when the toolbar was below the headings. My reason for that is:

• I often click on a header to see its sub headers
• Then I want to "close" and hide the sub headers again (because I've seen what I need)
• To hide them, now I have to click on a different point in the UI

So, placing the toolbar above the header line makes the important UI element (the header line) jumping around. That was also unintuitive for my dad ;)

I just tested org-web.org/sample and really like that more. One finger inbetween header line and content is no problem for me and better than a jumping header line.

Unfortunately I can't immediately offer a perfect solution, but hopefully we can all work together in this issue to design one. My current thinking is that if there are problems putting the toolbar below the header (as per #100) but also above it (as per #153, #169, and this issue), then maybe we need to find an entirely different approach. For example:

• Make it a lot smaller by changing DEADLINE / CLOCK IN / SCHEDULED into icons. I can't see any good reason why those buttons should be text but the others should be icons; am I missing something?
• Shrink the considerable padding between icons. Currently it's extremely space-inefficient.
• Once the toolbar was made smaller, perhaps it could be placed to the right-hand side of the header instead of above or below, without being overly intrusive. This might cause longer headers to wrap, but at least their top edge would not move. Or it could be floated to the right of the header, but just above it. In this case the previous header would be partially obscured, but that should not be an issue. The only catch is that this would not work for the first header in the file.

[schoettl]

• Make it a lot smaller by changing DEADLINE / CLOCK IN / SCHEDULED into icons. I can't see any good reason why those buttons should be text but the others should be icons; am I missing something?

The CLOCK IN turns to CLOCK OUT when clicked. OK, that could maybe changed to an "pressed-state" instead. But we would need at least 3 new icons that are time-related and recognizable! I don't see great icons for DEADLINE and SCHEDULED on https://fontawesome.com/, and even stopwatch would not be so self-explaining if you don't know all features.

So, just changing them to icons is not my preferred solution to make the toolbar smaller.

• Shrink the considerable padding between icons. Currently it's extremely space-inefficient.

On a smartphone, I would not shrink the space considerable. If the icons come much closer together, I cannot safely select the correct one.

• Once the toolbar was made smaller, perhaps it could be placed to the right-hand side of the header instead of above or below, without being overly intrusive. This might cause longer headers to wrap, but at least their top edge would not move. Or it could be floated to the right of the header, but just above it. In this case the previous header would be partially obscured, but that should not be an issue. The only catch is that this would not work for the first header in the file.

I think we cannot get the toolbar small enough, that it fits to the right – except this way (different UX topic): Menu button, see last point under 3. in #169.

[aspiers]

@schoettl commented on December 31, 2019 11:53 AM:

• Make it a lot smaller by changing DEADLINE / CLOCK IN / SCHEDULED into icons. I can't see any good reason why those buttons should be text but the others should be icons; am I missing something?

The CLOCK IN turns to CLOCK OUT when clicked. OK, that could maybe changed to an "pressed-state" instead. But we would need at least 3 new icons that are time-related and recognizable!

Yes maybe, or maybe it would be enough to have a single icon (clock or stopwatch or similar) which expands into the three options?

I don't see great icons for DEADLINE and SCHEDULED on fontawesome.com, and even stopwatch would not be so self-explaining if you don't know all features.

This is true, but I'd much prefer that we optimise the UI for regular users of organice rather than total newbies. IOW, some degree of learning curve is absolutely acceptable IMHO, as long as it's not too high. Although of course @munen would have the final say on this.

• Shrink the considerable padding between icons. Currently it's extremely space-inefficient.

On a smartphone, I would not shrink the space considerable. If the icons come much closer together, I cannot safely select the correct one.

I agree that there should still be padding between them. But currently there is space for about 3 more icons in between each adjacent pair, which means that in the space currently used by 5 icons, we could easily have 15 or more... That's a pretty huge level of space wastage ;-)

I think we cannot get the toolbar small enough, that it fits to the right

Based on my rough calculation above, I think we could fit 5 or 6 icons in the right-most 30% of the width. If we expanded that to two rows of icons, that's 10 or 12 icons!

except this way (different UX topic): Menu button, see last point under 3. in #169.

Yes, expanding buttons along the lines of a burger menu could definitely help. Here we should not rule out the possibility of having more than one icon which expands. I know that conventional UIs often only have a single burger icon which expands, but if we end up adding more actions in the future, it might be more efficient to have 2 or 3 icons which each expand to offer actions within a given category. Like I mentioned above, one icon could expand to offer actions relating to time (DEADLINE / CLOCK IN / SCHEDULED) but maybe there are other categories of action which could also be grouped together.

[munen]

The changes introduced in #100 didn't fare well with the community. Hence, as a first step to improve UX, we're reverting to the previous state. (FYI, @dotcs).

Thank you everyone for bringing your issues with potential changes up.

I'm not convinced that moving the current ActionBar any other place will solve the issue consistently. I'd argue that the issue is that organice has no clear UX guideline atm. There's a custom top bar, a custom action bar on items, custom notifications ("unpushed changes"), custom drawers and then there's material design in the bottom.

How about we embrace a well established UX paradigm like material design all the way? We could have a proper material design top bar, burger menu, bottom bar, menus, date pickers, snack bars and so on. There will be plenty space then - and users will find themselves more at home, because it'll be a known UX paradigm.

The only downside I see: It's a major refactor(; The upside: It's 100% possible to do this one step at a time.

If we agree to do this, the best way would be for someone to spend time on creating some mockups.

NB: I'm changing this issue from a 'bug' to a 'refactor' as the described buggy behavior was explicitly introduced and discussed through #100. The rationale is that bugs have higher priority than a refactor. It's important that organices feature set is bug free to the degree possible. It's also important to refactor improvable parts, but that's usually a longer term process than a bug fix.

[munen]

After reverting https://github.com/200ok-ch/organice/pull/190, the old title of the issue "UX: Header toolbar causes content to change position" is not actionable anymore.

Since the topic has drifted to a more general UX topic regarding on how to handle actions within organice, I updated the relevant metadata of the issue.

[munen]

A potential redesign should also solve the problem of creating headers on an empty file.

[munen]

@aspiers @schoettl: I've done a small step towards clearing up the HeaderActionDrawer:

All actions have icons. All icons have a mouseover. All actions are documented in sample.org

I just merged this PR: https://github.com/200ok-ch/organice/pull/215

For me, this is as good as we can make the UX with the current design. Anything further would have to be done in a more disruptive UX redesign (for example with material design).

Let me know what you think.

[schoettl]

You found good icons! I would as a next step, refactor that bar and create a "..." button to hide less important buttons and also to give them a caption that is visible on the phone.

Wouldn't it be better to switch the icons for clock-in and clock-out?

If the time is not running, the Sanduhr should not be able to run. And when I start the time, I have to turn it around, so that it runs.

[munen]

You found good icons!

Thanks! I made a brainstorming session with my wife and I'm quite happy with the result, too^^

I would as a next step, refactor that bar and create a "..." button to hide less important buttons

On my iPhone, they each have about 1cm space. For me, it's quite easy to hit the icons. And those modern Androids, they are probably double the size of my phoneg

I'd personally hold off with more improvements on this old UI and would start planning the new UI iteration.

and also to give them a caption that is visible on the phone.

Is that possible? Since a phone has no mouse, it has no mouse over. I wouldn't be aware of such a pattern, but I'd be stoked to learn something new(; If you know of an app that does it or of documenation, please send me a link.

Wouldn't it be better to switch the icons for clock-in and clock-out?

Good question! The icons are called fa-hourglass-start and fa-hourglass-end and that's how I used them. I guess that's because they are actions, so they indicate what they will do. For example a 'scissor' icon will cut something, but hasn't cut, yet. Hence, the hourglass with the sand on top will start the action 'clock in'.

I do understand what you're saying and it does create a little bit of mind fuck for me, too. But after some thought (and initially being inclined to change it right away), I think that icons are actions and they indicate what they will do when clicked.

I'm open to have my mind changed a third time, of course(;

[schoettl]

I would as a next step, refactor that bar and create a "..." button to hide less important buttons

On my iPhone, they each have about 1cm space. For me, it's quite easy to hit the icons. And those modern Androids, they are probably double the size of my phoneg

I'd personally hold off with more improvements on this old UI and would start planning the new UI iteration.

Yes, that probably make sense. Actually, my reason for this suggestion was not because the icons are so close together but because they take two lines. I just think it would look nicer if it was one slim line of actions.

and also to give them a caption that is visible on the phone.

Is that possible? Since a phone has no mouse, it has no mouse over. I wouldn't be aware of such a pattern, but I'd be stoked to learn something new(; If you know of an app that does it or of documenation, please send me a link.

For example, the Google Drive App: For each item (folder/file) it shows an vertical "..." button which opens a menu. Not the kind of context menu I expected but a pop-up menu anyway. And in the pop-up menu there are the icons together with captions.

[schoettl]

Wouldn't it be better to switch the icons for clock-in and clock-out?

Good question! The icons are called fa-hourglass-start and fa-hourglass-end and that's how I used them. I guess that's because they are actions, so they indicate what they will do. For example a 'scissor' icon will cut something, but hasn't cut, yet. Hence, the hourglass with the sand on top will start the action 'clock in'.

I do understand what you're saying and it does create a little bit of mind fuck for me, too. But after some thought (and initially being inclined to change it right away), I think that icons are actions and they indicate what they will do when clicked.

I'm open to have my mind changed a third time, of course(;

Now I understand, why the naming makes sense: If you see it as actions.

In this case however:

We don't have place to indicate the current status except with the icon. But I would say it is a design pattern to let the user see the current status. Take GitHub, "Star repository". Here, the icon shows the status, the text beside describes the action. Or the on/off switches in a settings menu. It displays the status.

In our case, we have the choice between showing the status and showing the action (in a state-changing action!) I would go with showing the status.

[schoettl]

On the other hand... the clock feature is different from a switch or the star (for repos). It's not an option that can be so or so. It's in fact more an action. It's difficult and confusing, and this is why we need the captions for the icons, in a pop-up menu ^^

The stop watch icon would also be a goot choice for starting the clock. But how to switch it off then...?

[aspiers]

This is awesome! Definitely way more space-efficient. My first instinct is to agree with @schoettl that it would be better to have the icons on a single line, with a ... or burger icon expanding to offer some of the less common actions. However the problem with this is how to decide which actions are less common, since in practice this will vary per user.

Wouldn't it be better to switch the icons for clock-in and clock-out?

Haha, I had the exact same reaction when I saw the icons, before reading the comments here... Yeah this "state/action ambiguity" plagues the design industry :-( On the flip side, that means there are plenty of good suggestions already out there, e.g.

• gui design - Should a toggle button show its current state or the state to which it will change? - User Experience Stack Exchange

It seems that the best answer to this question is "yes", i.e. it should show both the current state and the action. Unfortunately that doesn't help us in our space-constrained scenario. FWIW my suggestion for a minor improvement would be to replace one of them with hourglass-o and the other with hourglass-half - the rationale being that relying on black vs. white to imply start/stop is pretty ambiguous, whereas an empty hourglass has more clear connotations of nothing happening, and a half-way hourglass clear implies things are happening.

But that still doesn't fix the state/action ambiguity. Making it green when in progress (but keeping it grey when not) would help further, but is still not a full solution.

[munen]

One more thing to consider for a replacement of the header action bar: Maybe make all actions behave the same way. Right now we have inline editing vs. drawers.

More info see issue: https://github.com/200ok-ch/organice/issues/216

cc @aspiers

[aspiers]

Personally I like the way it is right now; I think inline editing makes sense for editing the title/body, and drawers make sense for editing tags/properties etc.

But of course I'm very willing to be persuaded otherwise if someone proposes a new design :-)

[munen]

Note: Within the new design, adding a global option for “collapse all headers” is also a good option.

Initially discussed here: https://github.com/200ok-ch/organice/issues/152

[munen]

Another plus for the redesign: The settings switches aren't clear to all users (are they toggled on or off). When switching to Material Design, they will be more familiar.

[aspiers]

I just had an epiphany regarding this, while watching a [spacemacs video which included a] quick demonstration of orgzly. With orgzly, if you want to edit any aspect of a header, you tap on the header and it opens a whole new page which allows you to set any/all of the following:

• header
• tags
• state
• priority
• scheduled timestamp
• deadline timestamp
• properties
• description

IMHO this modal approach has several advantages:

• Switching to a new header page automatically narrows the view to the current header, which on a small display makes sense, because generally it's more useful to give space for quick reads/writes of everything within that header, than to continue to use part of the screen for displaying random bits of context above/below the selected header:
• It eliminates the need to cram a bunch of icons into a small space. According to Fitts's law, the current design is somewhat weak in this regard.
• It's more aligned with standard mobile UI design.

Could this be the answer we are looking for?

[schoettl]

I think, we can't get around some sort of toolbar. Either a toolbar at the selected header or a toolbar that is always on top or bottom.

Because for some actions I don't like to leave the outline view and be force to open the "edit modal" (edit mode). For example:

• Clock in/out should be easily accessible, not behind the edit function.
• To set a timestamp, we probably still need an extra timestamp modal. So, for SCHEDULED/DEADLINE, I prefer one click to get to the timestamp modal directly.
• Same for tags, it will require an extra modal, and that should be accessible directly.

I don't think that we can integrate all current modals into a new edit model. So essentially, having our current modals only reachable behind a new header edit mode is often one click more.

The advantages I see with an edit mode, are having a cleaner view on the current header and no toolbar interrupting the outline view. However, even when editing the description field, it might be useful to see the subheaders, i.e. not leave the outline view.

The thing that I like least in the current UI is that the header toolbar shifts the outline view around. If the toolbar was just inline (same hight as normal header), it would be better IMO.

I attached a wireframe with a toolbar always sticking on top. Maybe you can also illustrate how a edit mode could look like.

Another approach would be to have the header toolbar as is, but in-line at the right side of the title. Only for the selected header and only with very few icons. But with a "…" button for hidden, less frequent used actions.

[aspiers]

@schoettl commented on June 13, 2020 12:50 PM:

I think, we can't get around some sort of toolbar. Either a toolbar at the selected header or a toolbar that is always on top or bottom.

Fitt's Law would indicate that placing it at the selected header is better.

Because for some actions I don't like to leave the outline view and be force to open the "edit modal" (edit mode). For example:

• Clock in/out should be easily accessible, not behind the edit function.

I agree that clocking in/out is semantically somewhat different to other types of editing. OTOH, I don't yet see any downsides of putting them within an "edit header" modal.

• To set a timestamp, we probably still need an extra timestamp modal. So, for SCHEDULED/DEADLINE, I prefer one click to get to the timestamp modal directly.

Currently it takes two taps: one tap on the header, then one tap on the SCHEDULED or DEADLINE icon. I don't see any practical way to reduce this to one tap. Am I missing something?

• Same for tags, it will require an extra modal, and that should be accessible directly.

I don't think that we can integrate all current modals into a new edit model. So essentially, having our current modals only reachable behind a new header edit mode is often one click more.

Sorry, maybe I'm missing something because I don't follow this argument. Like I said above, currently reaching a place where you can edit any aspect of a header takes two taps: the first to select the header, and the second to select which aspect to edit. My main point here was that after the first tap to select the header, it seems better to me to make use of the whole screen to show everything related to that header, for at least two reasons:

1. It provides the user a fuller context within the header they are editing; to take a random example, they could look at which properties are assigned and use that to help decide how to edit the tags.
2. It eliminates the problem of squeezing many edit operations into a relatively small icon bar. This in turn solves problems like the fact that the SCHEDULED and DEADLINE icons currently look extremely similar and I personally struggle to remember which is which.

The trade-off is of course that a full-screen edit modal prevents display of the context surrounding the header, i.e. the headers before/under/after it. But depending on the scroll position within the main view of the whole file, either the context before/under/after the header to be edited might have been missing anyway. For example if the header to be edited was at the top of the screen, the user can't see any headers before it, and similarly if it was at the bottom of the screen. So I don't see this loss being significant relative to the two advantages I listed above (and there may be others I missed).

The advantages I see with an edit mode, are having a cleaner view on the current header and no toolbar interrupting the outline view. However, even when editing the description field, it might be useful to see the subheaders, i.e. not leave the outline view.

Yes, this is a good point.

The thing that I like least in the current UI is that the header toolbar shifts the outline view around. If the toolbar was just inline (same hight as normal header), it would be better IMO.

Checking I understand correctly - your suggestion here is to roughly halve the toolbar height. Would you then try to squeeze all icons onto a single line? If so I suspect that the size and lack of space between them would cause problems.

I attached a wireframe with a toolbar always sticking on top. Maybe you can also illustrate how a edit mode could look like.

Sure, I would propose more or less copying orgzly's edit dialog:

Another approach would be to have the header toolbar as is, but in-line at the right side of the title. Only for the selected header and only with very few icons. But with a "…" button for hidden, less frequent used actions.

Yes, that's a possibility, but the "…" button would introduce a requirement for an extra tap which I personally I would find far less preferable to having a dedicated full-screen edit modal. What would be the benefit to justify requiring the extra tap?

[munen]

Nice that there’s a potential option being discussed!

In Orgzly, how do you get to this “edit screen”? Or asked differently: How would you propose to navigate to it in organice? Would it be a single action on a header whilst tapping continues to fold/open?

[aspiers]

@munen commented on June 14, 2020 3:19 PM:

In Orgzly, how do you get to this “edit screen”? Or asked differently: How would you propose to navigate to it in organice? Would it be a single action on a header whilst tapping continues to fold/open?

I think I really like how Orgzly does it:

https://youtu.be/PVsSOmUB7ic?t=2261

i.e. tap on the header opens the edit screen, and there is a dedicated + / - for expand/collapse. The latter has the advantage of giving a visual indicator whether a heading can be expanded or collapsed. (Notice that the absence of the + / - is further useful information from a UX perspective.)

There is maybe even room for improvement on Orgzly: the + / - could replace the existing bullets on the left, thereby saving screen space for display of more header info.

[aspiers]

I just realised that one of the things about the current UI I don't like is that it conflates two orthogonal actions into a single gesture (i.e. tapping the header): a) showing the toolbar and b) expanding the header. This means for instance I can't expand the header without also getting the toolbar. The workaround is to then tap the page header to hide the toolbar again, but obviously this is somewhat irksome.

Again I prefer Orgzly's approach here, because it keeps them separate: a tap (or long tap) on the header offers Orgzly's equivalent of the organice toolbar (i.e. switching to the edit page), and a tap on the + / - offers expand / collapse of the header. I also really like how Orgzly offers an icon at the top right which is the rough equivalent of Shift-TAB in emacs.

[schoettl]

@schoettl commented on June 13, 2020 12:50 PM:

I think, we can't get around some sort of toolbar. Either a toolbar at the selected header or a toolbar that is always on top or bottom.

Fitt's Law would indicate that placing it at the selected header is better.

True

Sorry, maybe I'm missing something because I don't follow this argument.

I think we actually have similar problems with the current behaviour and toolbar.

OK, it may partly be the same number of clicks with an editor modal vs. the inline toolbar.

My point is, that for many actions I'd prefer to stay in the outline view. Clock in/out and setting timestamps should be a quick action and switching to the edit mode would distract me. I don't want to lose focus, I'd like to stay on the outline view for such actions.

So, I'm in favor for a inline-toolbar that doesn't makes the outline shifting around. I'm absolutely not against an edit mode. I think we can have both.

---

Another UX design proposal:

* Currently not selected header
** Selected header ...              [clin] [clout] [sched] [edit] [...]
** Not selected header ...

• [xx] means an icon button.
• Long-press or click on [edit] could open the edit modal.
• I think, that collapse/decollapse is so important that it should be the default click action on any point of the header.
• ... signal that there is collapsed content. As it is in current Organice and Org mode.

---

the SCHEDULED and DEADLINE icons currently look extremely similar and I personally struggle to remember which is which.

BTW, my mnemonic is: filled (black) calendar icon = hard deadline, empty (light) calendar icon is soft schedule date.

The trade-off is of course that a full-screen edit modal prevents display of the context surrounding the header, i.e. the headers before/under/after it. But depending on the scroll position within the main view of the whole file, either the context before/under/after the header to be edited might have been missing anyway. For example if the header to be edited was at the top of the screen, the user can't see any headers before it, and similarly if it was at the bottom of the screen.

Sure, but the user can make the surroundings of interest visible by scrolling. I think that is an advantage.

The thing that I like least in the current UI is that the header toolbar shifts the outline view around. If the toolbar was just inline (same hight as normal header), it would be better IMO.

Checking I understand correctly - your suggestion here is to roughly halve the toolbar height. Would you then try to squeeze all icons onto a single line?

I don't mean that all icons must be visible in the toolbar ^^ With an edit mode some actions might be redundant. Furthermore we could put as many icons in the toolbar as the display width allows. And put others in a "..." menu. This way, we can also sort by importance and hide less important actions.

Another approach would be to have the header toolbar as is, but in-line at the right side of the title. Only for the selected header and only with very few icons. But with a "…" button for hidden, less frequent used actions.

Yes, that's a possibility, but the "…" button would introduce a requirement for an extra tap which I personally I would find far less preferable to having a dedicated full-screen edit modal. What would be the benefit to justify requiring the extra tap?

As I said above, I see a benefit that I could keep focus on the outline view and not being distracted by an edit mode that I don't wanted to open. But let's see how many icons would be left and make sense in a toolbar, after we have an edit mode...

[schoettl]

@aspiers

I just realised that one of the things about the current UI I don't like is that it conflates two orthogonal actions into a single gesture (i.e. tapping the header): a) showing the toolbar and b) expanding the header. This means for instance I can't expand the header without also getting the toolbar. The workaround is to then tap the page header to hide the toolbar again, but obviously this is somewhat irksome.

My idea (see my previous comment), was to make the toolbar "inconspicuous" by having it in-line. For me, the thing that a tap has two meanings (collapse/uncollapse + "select") is not a problem.

And I think than collapse/uncollapse is a very important action in the outline, it should be the "default action", not the action of a small +/- button.

[aspiers]

@schoettl commented on June 15, 2020 5:00 PM:

@schoettl commented on June 13, 2020 12:50 PM:

I don't think that we can integrate all current modals into a new edit model. So essentially, having our current modals only reachable behind a new header edit mode is often one click more.

Sorry, maybe I'm missing something because I don't follow this argument.

I think we actually have similar problems with the current behaviour and toolbar.

OK, it may partly be the same number of clicks with an editor modal vs. the inline toolbar.

In which cases would it be different?

My point is, that for many actions I'd prefer to stay in the outline view. Clock in/out and setting timestamps should be a quick action and switching to the edit mode would distract me. I don't want to lose focus, I'd like to stay on the outline view for such actions.

OK, that's fair.

So, I'm in favor for a inline-toolbar that doesn't makes the outline shifting around. I'm absolutely not against an edit mode. I think we can have both.

Agreed!

---

Another UX design proposal:

* Currently not selected header
** Selected header ...              [clin] [clout] [sched] [edit] [...]
** Not selected header ...

What if the selected header is wide enough to fill the whole screen width? Or if it's wide enough to wrap around and fill two or more lines at full screen width? Do you then truncate it, or have the text flow around the buttons (e.g. placing the buttons via float: right or similar)?

• [xx] means an icon button.
• Long-press or click on [edit] could open the edit modal.

Unfortunately this doesn't work for me at all. Long-press would be too slow, and click on [edit] would require 3 taps for many operations (editing the title / description / tags):

1. Tap to select header
2. Tap to enter edit mode
3. Tap to select which thing to edit

My suggestion to add a new full-screen edit modal page was entirely predicated on it being reachable in a single tap. If it takes two taps to reach then it would be worse than what we have right now.

• I think, that collapse/decollapse is so important that it should be the default click action on any point of the header.

I think I agree with this.

• ... signal that there is collapsed content. As it is in current Organice and Org mode.

... seems less compact than + but I guess we can bike-shed that later.

the SCHEDULED and DEADLINE icons currently look extremely similar and I personally struggle to remember which is which.

BTW, my mnemonic is: filled (black) calendar icon = hard deadline, empty (light) calendar icon is soft schedule date.

Oh that's useful, thanks! :-)

The trade-off is of course that a full-screen edit modal prevents display of the context surrounding the header, i.e. the headers before/under/after it. But depending on the scroll position within the main view of the whole file, either the context before/under/after the header to be edited might have been missing anyway. For example if the header to be edited was at the top of the screen, the user can't see any headers before it, and similarly if it was at the bottom of the screen.

Sure, but the user can make the surroundings of interest visible by scrolling. I think that is an advantage.

OK, I can accept that even I suspect it wouldn't be particularly useful to me personally.

The thing that I like least in the current UI is that the header toolbar shifts the outline view around. If the toolbar was just inline (same hight as normal header), it would be better IMO.

Checking I understand correctly - your suggestion here is to roughly halve the toolbar height. Would you then try to squeeze all icons onto a single line?

I don't mean that all icons must be visible in the toolbar ^^
With an edit mode some actions might be redundant. Furthermore we could put as many icons in the toolbar as the display width allows. And put others in a "..." menu. This way, we can also sort by importance and hide less important actions.

One problem here is that different actions will have varying degrees of value to different users. Some people might use priorities (say) all the time, and others never. So unless this is configurable I can't see it being very popular.

Another approach would be to have the header toolbar as is, but in-line at the right side of the title. Only for the selected header and only with very few icons. But with a "…" button for hidden, less frequent used actions.

Yes, that's a possibility, but the "…" button would introduce a requirement for an extra tap which I personally I would find far less preferable to having a dedicated full-screen edit modal. What would be the benefit to justify requiring the extra tap?

As I said above, I see a benefit that I could keep focus on the outline view and not being distracted by an edit mode that I don't wanted to open. But let's see how many icons would be left and make sense in a toolbar, after we have an edit mode...

What would your criteria be for deciding what makes sense in a toolbar vs. an edit mode?

[aspiers]

@schoettl commented on June 15, 2020 5:07 PM:

And I think than collapse/uncollapse is a very important action in the outline, it should be the "default action", not the action of a small +/- button.

I'm fine with that idea; I think that editing is also very important though. So both Orgzly's approach (tap anywhere on the header to edit, or on a small +/- button to expand/collapse) and the reverse (tap anywhere on the header to expand/collapse, or on a small button to edit) suffer from the same problem: one important action is accessible via a small button. Again this is poor UX when considering Fitt's Law.

So here's another idea which could offer the best of both worlds! Tapping anywhere on the header will either edit or expand/collapse, depending on whether the tap is to the left or right of the centre of the screen. That way we offer a large surface area for both editing and expand/collapse, and both can be accessed instantly with no long-press required.. It would also be easy to offer the user a choice of which way round those areas were assigned to the actions. What do you think?

[Historical side-note: IIRC, this technique was used either in the Pimlical Android calendaring app, or perhaps even many many years ago by its predecessor DateBk6 back in the Palm / Treo era (I had a Treo 650 which was amazing).]

Taking it further, we could offer the user a choice of whether the edit action opens an inline action bar with a set of icons, like it does currently, or opens a dedicated edit modal just for that header. And if they choose the former, eventually we could offer the choice of which actions are immediately accessible via icons, and which ones would require an extra tap to access.

Of course, this would be a far amount of work to code, but I'm pretty sure we could implement it incrementally, bit by bit.

[munen]

I love that this discussion is taking place here. Just wanted to quickly jot down a few words on what comes to mind for me on this topic. Nothing decided, or well formulated, just adding to the brainstorming session.

Firstly, thanks to both of you for the active discussion.

• Generally speaking, I really like the idea of an edit screen.

  • It gives more space to editing.
  • It's similar to good old fashioned CRUD web apps like Rails where it also always was a good idea to keep the editing in the Edit screen. Only 'in the new days' of SPAs, all the actions had to be cramped on the main screen. That's possible if it's possible. But sometimes you run out of space, or you don't have a UX team that can figure it out differently.
  • I can also see how it unifies the different types of modals we are using right now into one screen.
  • What I'd like most is that when I create a new header, I can do all the things to the header that I want to do (like give it a planning item). Very often I create a header and then have to edit it right away.
  • I agree that the current UX conflates to things in one action (tapping is folding and showing actions). That's necessarily great. It's there, atm, because it saves screen estate. The other reason is that - all things being equal - a user who taps the header is as likely to want to read stuff below or interact with the header. I think it's quite common to just tap on things these days if you want to interact with them - or get more context. If we find a different way that we all like better, let's go for it!

• I also like the points made by schoettl

  • In particular, I think that tapping is a sane default for folding. To the best of my knowledge, many users just read their Org files and only modify them slightly. That's underlined by tools like Orgro. I'm not saying that editing is not important, but imo the main actions in organice on a mobile device are:
  • Reading/Looking up
  • Finding stuff to read/modify
  • Capturing

As for the 'total unfold/fold' feature in the headline: I've actually been thinking of doing that. I find myself quite often to open organice and seeing it in a somewhat random 'openness state'. It's not random, of course, it's how I left it. But for my new task, which might be semantically different, it's the same as random. I do the same in Emacs (S-T) quite often, too.

My big open question with regards to an editing screen is: What do we do with the many actions that are not "editing actions"? They don't immediately map well (in my mind) to the concept of hiding state change behind a pull down in the edit screen like in Orgzly.

When you count the actions on the header bar, there's a total of 11. However, "only" 6 of them (edit title, edit description, tags, properties, schedule, deadline) are direct editing actions. These are not:

• track time (just starts/stops a process, doesn't need a pulldown)
• focus/unfocus (akin C-x n s, is a reading feature)
• refile (akin C-c C-w, is a sorting feature, not editing the header)
• share/email (doesn't edit the header)
• add header on the same height (akin C-RET, doesn't edit the current header)

I guess the 'big open question' would lead to a compromise similar to what schoettl suggested. Some actions stay on the header, some move to a modal.

I'm not sure, though, how it would work to put the current 5 non-edit actions (and possible future ones) to the right of a header. Maybe I'm the only one, but my headers are often quite a bit longer than one line (especially if already nested), so they flow into multiple lines. If we reserve space for 5 icons, I guess we'd only have about 2/3 of the screen width for the header itself. I'd have to make a quick mockup to see what that looks like.

More random notes:

• I'm not sure how well 'long press' maps to a SPA. On iOS, 'long press' maps to selecting text, not a custom action. iOS used to have 'force touch', but that's gone in iPhones after the Xs.
  • So, from a UX perspective, I think it would be hard to gauge for an iOS user.
  • From a technical perspective, I don't know if it's possible to safely override the native browser functionality of selecting text. Without having tried it, I doubt it. And if it worked now, I'd be afraid that Apple would see that as a regression and kill it at some point.

Having said that, to take from stock iOS apps, they sometimes give access to more actions through 'force touch' or 'partial move to left'. We could theoretically use the latter, but I personally don't like it and don't even use it in native apps.

I think the idea of having a fold for the action on the left and right is pretty intriguing. That could be something. If we could find something that a semi-popular app of these days uses, that would be more preferable, because it'll be easier for users - and tapping left or right is not easily discoverable. Personally, I'm liking the idea, though!

Ok, enough of my unsorted thoughts. It's really just a brain dump. I like it a lot that more brain power is spent on the UX topic. Thanks, guys! 🙏

[munen]

By the way, since we are redesigning, I think both the ideas of having some fixed actions in a header and an edit view map very well to the desktop version. Careful, super rough sketch ahead:

[schoettl]

Having said that, to take from stock iOS apps, they sometimes give access to more actions through 'force touch' or 'partial move to left'. We could theoretically use the latter, but I personally don't like it and don't even use it in native apps.

On Android:

• for normal websites in browser, long press triggers the selection/copy mode
• for most Apps (and I would call an SPA an app, not a web page), "long press" triggers a "context mode", i.e. it shows a toolbar and marks the item as selected.

I cannot find the 'partial move to left' in Android, so I don't like this option ^^

I'm a bit surprised that there seems to be no common "context mode" action in iOS and Android...

[schoettl]

I'm not sure, though, how it would work to put the current 5 non-edit actions (and possible future ones) to the right of a header. Maybe I'm the only one, but my headers are often quite a bit longer than one line (especially if already nested), so they flow into multiple lines. If we reserve space for 5 icons, I guess we'd only have about 2/3 of the screen width for the header itself. I'd have to make a quick mockup to see what that looks like.

How do you think of my proposal of the "…" button in the header toolbar for other (less frequently used) actions? Don't know if this UI concept is common on iOS, but we have it on Android (not only in the top menu but also for items (e.g. Google Drive App). It's similar to the "burger icon" in Firefox/Chrome, it opens a context menu. And on Android, I remember there was a concept of "Overflow Menu on Action Bar" which pushes icons into this "…" menu depending on the display width.

[aspiers]

@schoettl commented on June 17, 2020 10:33 PM:

I'm not sure, though, how it would work to put the current 5 non-edit actions (and possible future ones) to the right of a header. Maybe I'm the only one, but my headers are often quite a bit longer than one line (especially if already nested), so they flow into multiple lines. If we reserve space for 5 icons, I guess we'd only have about 2/3 of the screen width for the header itself. I'd have to make a quick mockup to see what that looks like.

How do you think of my proposal of the "…" button in the header toolbar for other (less frequently used) actions? Don't know if this UI concept is common on iOS, but we have it on Android (not only in the top menu but also for items (e.g. Google Drive App). It's similar to the "burger icon" in Firefox/Chrome, it opens a context menu. And on Android, I remember there was a concept of "Overflow Menu on Action Bar" which pushes icons into this "…" menu depending on the display width.

In terms of discoverability and intuitiveness it's good, but I think if this was the only way to reach actions hidden within the "…" menu, I'd personally hate it on account of the extra click required. IMHO this would be optimising for new users at the expense of experienced regular users, and in general I really dislike that kind of approach to UI design, since I believe users should be rewarded for climbing the learning curve, not punished ;-)

OTOH, if there is another "advanced" way of reaching all the actions quickly, such as my "tap on the left or right half of the screen" idea, then a "…" menu would probably do no harm.

[munen]

for normal websites in browser, long press triggers the selection/copy mode

Same on iOS.

for most Apps (and I would call an SPA an app, not a web page), "long press" triggers a "context mode", i.e. it shows a toolbar and marks the item as selected.

That's what 3d touch does since the iPhone 6. With 3d touch, you've got three layers: Regular touch, slight force, more force. The second layer would be the context mode. It's being replaced by 'haptic touch' starting from the iPhone XR. I have an Xs, so the last model with 3d touch. Hence, I've got no experience with haptic touch. In any way, it's likely not the same as on Android-_-

I cannot find the 'partial move to left' in Android, so I don't like this option ^^

Honestly, it sucks anyway. For example in Mail.app, when you swipe left completely, you delete the mail (same as deleting a header in organice). But if you only swipe partially, you get three options (more, flag and delete). That's easy to miss and not fast to get to. So I never use it.

I'm a bit surprised that there seems to be no common "context mode" action in iOS and Android...

Agreed. Afaik, this has always been an issue for devs/designers trying to build a cross-platform (iOS/Android) app-_-

How do you think of my proposal of the "…" button in the header toolbar for other (less frequently used) actions?

Honestly, I wouldn't know why which ones that would be. That's the downside of having no analytics, we have no data on that. Personally, I use them all (with the exception of Share via Mail) pretty equally and pretty often. Of course, I'm only a sample size of 1, so it doesn't count a lot(;

I'm thinking about your proposal to put the actions directly under the header-bar, though. Imo, it would make sense to make the header-bar sticky, anyway. Undo/Redo are pretty inaccessibly atm. I'm not certain (as in completely undecided, neither pro nor con) if we can move two rows of icons underneath the header-bar, though. It would use up a lot of space. For the desktop version (as indicated in the rough sketch), that definitively works! For the mobile version, if we can get them down to half the icons (for example because the other actions are in a new edit screen), it could work. But even for that, I'd have to try and see.

Having said all that, there are quite a few apps using the "…" idiom, though! For example FB and LinkedIn. Twitter does the same with a "🢓". I'd say it's definitively a widely used idiom.

I'm still thinking that the best way for a re-design is to stick with a specific design framework. Specifically, I'm thinking of Material Design, because it's widely used on both platforms and on the web. A possible place for the actions could be a bottom app bar: https://material.io/components/app-bars-bottom

[munen]

OTOH, if there is another "advanced" way of reaching all the actions quickly, such as my "tap on the left or right half of the screen" idea, then a "…" menu would probably do no harm.

That's not an uncommon methodology: Make it accessible to the beginners, but give experienced users more powerful tools. The click left/right feature could also be a setting that has to be enabled. Then it wouldn't confuse beginner users, but more experienced users get the benefit of configuration and power.

[aspiers]

Agreed - exactly!

[aspiers]

I had another look at Orgzly today, and I have to admit (perhaps somewhat grudgingly!) that they have done a damn good job with the UI. I only just noticed that you can swipe left or right on each note to open an icon menu just below it, which is quite like the organice icon menu except it's quite a lot less intrusive and cluttered, because it's only one row, with 4 icons which vary depending on whether you swiped left or right. So I think this gesture approach would be a really thing to steal.

[munen]

(Can't check myself, don't have an Android), are you preferring this to toggling 'done' states and deleting notes through swiping? Tbh, I quite like those actions and use them a lot. On iOS, it's also a common UX theme. For example the official Mail.app toggles read/states with a right swipe ('done' states) and deletes with right. Reminders.app (the official todo list app) deletes on left swipe, Messages.app does the same.

Adding icons on swipe sometimes happens in apps. For example Evernote shows three icons on a right swipe on a note (one of them delete).

[aspiers]

@munen commented on July 11, 2020 6:41 PM:

(Can't check myself, don't have an Android), are you preferring this to toggling 'done' states and deleting notes through swiping?

I think I momentarily forgot somehow that Organice already has left/right swiping gestures :laughing:

But I think I would use an edit screen far more often than deletion, so yes I would prefer a swiping gesture or quick access for the former to the latter. Quick change of keyword state is also very useful for me.

Tbh, I quite like those actions and use them a lot. On iOS, it's also a common UX theme. For example the official Mail.app toggles read/states with a right swipe ('done' states) and deletes with right. Reminders.app (the official todo list app) deletes on left swipe, Messages.app does the same.

Yes, same with several Android apps too. Pocket Casts even supports two different actions from a swipe left, depending on how far you swipe.

Adding icons on swipe sometimes happens in apps. For example Evernote shows three icons on a right swipe on a note (one of them delete).

Interesting.

I suspect there is no single UI which will please everyone here, so maybe it's best to allow the user to choose what the various gestures do. Double-tap as per #254 and long-press for less frequently used actions might help too, if challenges such as debouncing can be solved effectively.