Page MenuHomePhabricator

Flow editing toolbar should be at the top of the edit window
Open, Needs TriagePublic

Description

In nearly every other interface within MediaWiki the controls for interacting with content is above the actual content. That's not the case in Flow.

Examples of other interfaces:

  • Navigation menu (Username, Talk, Preferences, Watchlist, etc)
  • Tabs for Read, Edit, View History
  • VisualEditor
  • Wikitext editor
  • Nearly (all?) Special: pages (RecentChanges, Contributions, etc.)

Other bits of the MediaWiki universe that have their controls at the bottom:

  • Echo - In the drop-down sheet "All notifications" and "Preferences" are at the bottom, but that's for another task :)

Akin to designing applications that are specific to an operating system, there are best practices to make the application feel congruent with the use of other applications on the same platform. In this context Flow's bottom toolbar feels out of place.

See also:

Event Timeline

Ckoerner created this task.Feb 25 2016, 3:42 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptFeb 25 2016, 3:42 PM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald Transcript
Quiddity updated the task description. (Show Details)Mar 3 2016, 6:39 PM
Quiddity added a subscriber: Quiddity.

I also think that bottom-positioned toolbars are a bad idea when combined with context menus that can't be closed. Consider this case, with a context menu for an item at the bottom of the editing area:

Should we have the context menu cover the bottom toolbar (potentially making its tools inaccessible when the cursor is in the wrong place), or should we have the bottom toolbar cut off the context menu (potentially making its actions inaccessible)? Toolbars on top do not have this problem.

Consistency is important, but adapting the solutions to their context is important too. In this case Flow adapts the toolbar with the goal to lower the barrier to participate by doing the following:

  • Put the message first by placing the tools after the content.
  • Make it feel lightweight, by presenting the tools as part of the text area you are editing.
  • Surface specific needs such as a quick access to mention which are not as relevant in other editing content but are common in this one.

When participating in a discussion it is totally fine to send a message without the need to do advanced formatting. Introducing all the possibilities of what you can do in terms of formatting before you had the chance to write your message seemed to unnecessarily raise the barrier for contribution.

I think the current approach helps to tell users that they can just type what they want to say and send it, while users that need to elaborate more complex content are able to find their tools despite the customisation. I think it is a reasonable balance.

I also think that bottom-positioned toolbars are a bad idea when combined with context menus that can't be closed. Consider this case, with a context menu for an item at the bottom of the editing area:
Should we have the context menu cover the bottom toolbar (potentially making its tools inaccessible when the cursor is in the wrong place), or should we have the bottom toolbar cut off the context menu (potentially making its actions inaccessible)? Toolbars on top do not have this problem.

I don't think the issue invalidates the whole approach. We can explore some solutions to alleviate the issue if we observe that happening often:

  • Provide some extra space for the user to be able to scroll the content and avoid the overlap.
  • Make the tooltip to be shown above the associated element in those cases.
Restricted Application added a project: Growth-Team. · View Herald TranscriptSat, Oct 12, 4:11 AM