Hi Olivier, > On 25 Apr 2017, at 11:34, oseres <ose...@xwiki.com> wrote: > > @Vincent : as a PO, you should stay positive in commenting enhancement > proposals of others, avoid subjective statement as : "I don't like" or > denigrant "WTF" expression.
1) PO has no meaning on this list. I’m a committer like any other here. 2) I’m giving my opinion so it is my POV ofc and that’s what we’re asking to everyone here. Don’t take it badly, it’s not personal. 3) I’m not just saying that I don’t like it much, I’m also taking the time to provide some arguments… 4) You didn’t reply to Caty’s proposal and instead you just made another proposal. In general I’ve observed in the past that you rarely comment on what exists or what people propose and instead you have a tendency to want to propose something new coming from you. I appreciate (really I do) that you take the time to make proposals but it would also be nice to comment on other people’s proposals. For example I’d be interested to understand what you don’t like in Caty’s proposal that’s making you propose something different and whether or not you find Caty’s proposal interesting. > @Vincent @Edouard : I think your opinions on this Action Toolbar > proposition are too dogmatic : if a change makes the software easier to > learn I think it's acceptable so break some rules. However, I accept that > the burdon of proof is on me to show that this is indeed likely to improve > user experience and learnability. And also why your proposal is better than Caty’s in your opinion (ie what it solves that Caty’s proposals don’t). > Here's why I think this change will improve learnability and UX : > > * I think users need to associate that Edit and Save form the major workflow > of page modifications. Putting the 2 buttons next to each other reinforce > the understanding of the workflow by newcomers Yes but the counter argument is that the flow goes from top to bottom: as user enter text they move more and more to the bottom. So the bottom is a logical place to find the save. Also on all UIs I know and on all our Admin Screens for example the validation buttons are always at the bottom. See https://tinyurl.com/mx8j5re and you’ll see that all UIs have validation buttons at bottom. > * There is no strong reason not to have Save available at the bottom of the > document, I just believe that it needs to also be available at the top too > so users see it and not scroll I’m not convinced that it’s a good thing to have the same buttons in several places. One drawback of course is that you remove all the options that currently exist in the page content menu (switch editors, edit admins options for the page, etc). If the save buttons are always visible even we scroll I don’t see any compelling reasons to loose the current features by replacing them with another duplicated save button. > * Other wikis (including Mediawiki in their Visual Mode and SharePoint wiki > ) put the Save Button next to the Edit One (see http://d.pr/i/Qvw8 and > http://d.pr/i/rpoJ), they probably have put some effort into usability and > so we should consider taking advantage of their effort. > <http://xwiki.475771.n2.nabble.com/file/n7603611/Screen_Shot_2017-04-25_at_11.png> > > Further more, in other contexts (editors, e-commerce websites), major "final > action" ("Publish", "Add to the Cart" are most of the time in the top of the > page, so users don't miss it) Yes that’s a good point but the same argument applies to other wikis. Just to give 3: * Confluence: https://marketplace-cdn.atlassian.com/files/images/ecbea49f-8a0c-49d0-9d56-e5f12555a207.png and * Dokuwiki: https://www.dokuwiki.org/features?do=edit * TikiWiki: https://tinyurl.com/lcrk3pj > * It is more efficient to do one click rather than two (and other software > such as Thunderbird accepts to mix buttons like "reply" which start an > action but do not complete it with buttons such as "delete message" which do > complete an action; GMail also mixes 1-step and 2-steps actions buttons) I don’t understand this point. Caty’s proposals and the current way it’s implemented is just one click to save. > * Switching between editor types seems like an advanced feature, it is not > exposed to simple users which should be most users It’s not just that but also all the other features (see the other actions). But even that is important; we certainly don’t want to only have simple users in XWiki. We also need to cater for the needs of advanced users. > @Vincent : I took your Version summary concern into consideration and made a > new proposal here > : > http://design.xwiki.org/xwiki/bin/download/Proposal/Idea%3A%20Contextual%20Actions%20Toolbar/ContextualToolbarEditModeZoom.png > (also > avoiding a popup) Thanks. I still find it a strange UI (it’s strange to add options under a menu). So that I understand: when the user clicks save (not the arrow) what happens? The save menu always open? Again don’t take it badly but I still find Caty’s proposal closer to the initial need (make the save always visible - your proposal has the issue of loosing sight of the bar when you scroll down, that’s the main problem we’re solving), more natural (doesn’t repurpose buttons), more powerful (still allows to switch edit modes and perform other actions - this one would be a major pain, I use that all the time, switching from one editor to another for example) and more visible (it’s more logical to look for save at the bottom than at the top IMO since the flow goes from top to bottom). Thanks -Vincent > View this message in context: > http://xwiki.475771.n2.nabble.com/Proposal-UX-Visible-Save-buttons-tp7603449p7603611.html > Sent from the XWiki- Dev mailing list archive at Nabble.com.
