Re: [xwiki-devs] Fwd: [Discussion] New location of the "Add" menu in the new Flamingo skin

On Fri, Oct 3, 2014 at 3:28 PM, vincent(a)massol.net wrote: As I said in the proposal "Well known actions are represented with icons, while we provide text only for user generated entities (Wiki/Space/Page/User names)”.

I've also iterated on the 'green color' idea, see http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocation… http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocation… but I prefer the initial proposal (with white) since I think the contrast is better and also we keep consistency between elements.

I've created http://jira.xwiki.org/browse/XWIKI-11166 and http://jira.xwiki.org/browse/XWIKI-11167 Thanks, Caty > > The rest is fine to discuss and tune for 6.3+ IMO. > > Thanks > -Vincent > > > Thanks, > > Caty > > > > > On Fri, Oct 3, 2014 at 1:43 PM, Eduard Moraru wrote: > > > > > Big +1 for Var3 for the simple fact that it looks like a > "holistic"/global > > > approach that does not only focus on a specific element, like the "Add" > > > button and currently falls into the mistake of making it a bright shiny > > > beacon to misguided users, resulting in something that is overall > > > disturbing to the eye. Same can be said about the "Search" element, > since > > > it now reduces the heavy contrast of both the search input (bright > white on > > > dark background) and its search button (bright colored blue on dark > > > background). > > > > > > About the Search button (re: Jeremie): Because it is the first element > in > > > its group, it will show to the left and no other elements will be > > > disturbed, so the transition will be nice for users. Basically the > expand > > > search button (the magnifying glass) becomes a button once you expand > it, > > > so there should be no flicker or anything like that. > > > - As an alternative, if we really are against > > > transitions/animations/expandable elements/etc, we could just present > the > > > search as directly expanded (classic way), but still keep the darker > input > > > color to avoid the "kitch" effect described above due to high > contrasts. > > > > > > About the + (Add) button, IMO, the only thing we could do more if we > really > > > want to emphasize it in an *elegant* fashion, would be to make the + > sign > > > itself green, or with some green border, whatever. Whatever we do, we > > > should try to consider Caty's opinion on style here since she might > have a > > > better eye and this proposal here seems to be towards that direction. > > > > > > IMO, one very interesting thing to note is the extended (3.4) version > and > > > long term view that we also need to take into account and, at least to > me, > > > that looks really slick. > > > > > > I think we should stick to the original intent of this Flamingo skin, > with > > > the addition of Bootstrap's style, and keep it slick, minimalistic and > to > > > the point. The users should focus more on the content instead of the > UI, > > > don`t u think? > > > > > > ------ > > > On a related note, If you ask me, I would be in favor of also removing > the > > > labels from "Edit" and "More actions" and just go with the *all too > > > obvious* "pencil" and "cog" icons. GMail uses the "cog" icon with 0 > > > problems and I kind of trust that their UX army did their research and > > > impact studies for that :) > > > > > > Also, on matters of "consistency" we would achieve the following > statement: > > > "Actions have only icons, while entities have an icon and a label that > > > displays the entity's name". > > > - Actions: add, edit, search, more actions, etc. > > > - Entities (with dropdown menu for actions on the entries): wiki, > space, > > > page, user. > > > ------ > > > > > > Let's keep this skin clean and a pleasure to work on/with, WDYT? > > > > > > Thanks, > > > Eduard > > > > > > On Thu, Oct 2, 2014 at 8:09 PM, Ecaterina Moraru (Valica) < > > > valicac(a)gmail.com > > > > wrote: > > > > > > > Hi, > > > > > > > > I've created this proposal > > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocation > > > > Please read it and give your opinion on it. The proposal is based on > > > > discussed solution, but improves a bit the styling. > > > > > > > > If you are curious how I reached some of the proposal's conclusions, > you > > > > can see it's iterations > > > > > > > > > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/FlamingoAddMenuLocationIter… > > > > > > > > Thanks, > > > > Caty > > > > > > > > > > > > > > > > On Thu, Oct 2, 2014 at 7:59 PM, Guillaume Lerouge > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > actually one thing we could try is this: > > > > > > > > > > - *Keep the "Add" button where it is and use it for page-related > > > > > actions:* > > > > > - "Add child page" > > > > > - "Add comment" (as suggested by Denis) > > > > > - "Add attachment" (as suggested by Denis) > > > > > > > > > > > > > > > - *Add a "Create" button in the top bar, with 2/3 options:* > > > > > - "Create page" (TBD) > > > > > - "Create space" > > > > > - "Create wiki" > > > > > - In this case, after clicking "Create" the user would be presented > > > > with > > > > > a page / modal box listing existing instances as well as available > > > > > templates > > > > > > > > > > I think this would solve both my issues (having less-frequent > actions > > > in > > > > > the same location as a more-frequent one, not being in the right > place > > > on > > > > > the page) and GuillaumeD's wife issue (the "Add" button is easy to > find > > > > > where it is right now, why move it?). > > > > > > > > > > WDYT? > > > > > > > > > > Guillaume > > > > > ᐧ > > > > > > > > > > On Thu, Oct 2, 2014 at 1:48 PM, vincent(a)massol.net > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 2 Oct 2014 at 13:31:56, Eduard Moraru (enygma2002(a)gmail.com > > > (mailto: > > > > > > enygma2002(a)gmail.com)) wrote: > > > > > > > > > > > > > On that note: > > > > > > > The funny/sad thing to realise is that we are basing all this > > > > > discussion > > > > > > on > > > > > > > the fact that some users did not find the "Add" button *only > the > > > > first > > > > > > > time* they tried to do something. The realization is that this > is > > > one > > > > > of > > > > > > > those things (idioms[1][2]) that you learn once and know how to > > > > easily > > > > > do > > > > > > > the next 1000x times (like riding a bike). > > > > > > > > > > > > > > The real problem appears when you are in those "next 1000x > time" > > > and > > > > > you > > > > > > > find it cumbersome to use (like riding a bike with no saddle, > or > > > with > > > > > the > > > > > > > saddle on backwards :) ). So in both cases (top or middle of > the > > > > page) > > > > > > once > > > > > > > you find it once, you will find it again, however in the > middle of > > > > the > > > > > > page > > > > > > > it conflicts too often with the Edit button and other page > related > > > > > > actions, > > > > > > > that it becomes cumbersome to use. > > > > > > > > > > > > Indeed that’s something I had in mind too. If you just ask to > add a > > > > page > > > > > > and that’s all then you’re not doing a full test. You’d need to > ask > > > the > > > > > > user to: > > > > > > - add a page > > > > > > - delete a page > > > > > > - move a page > > > > > > - create a space > > > > > > - etc > > > > > > > > > > > > And then only you can draw some conclusion IMO. > > > > > > > > > > > > Thanks > > > > > > -Vincent > > > > > > > > > > > > > Thanks, > > > > > > > Eduard > > > > > > > > > > > > > > ---------- > > > > > > > [1] http://thor.info.uaic.ro/~evalica/hci/L2/ > > > > > > > [2] > > > > > > > > > https://www.englishforums.com/English/IdiomsVsMetaphors/cqwl/post.htm > > > > > > > > > > > > > > On Thu, Oct 2, 2014 at 12:47 PM, vincent(a)massol.net > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2 Oct 2014 at 11:06:00, Guillaume Louis-Marie Delhumeau ( > > > > > > > > gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote: > > > > > > > > > > > > > > > > > Hi. > > > > > > > > > > > > > > > > > > I have done the "test-on-my-wife" thing :) > > > > > > > > > > > > > > > > > > She finds it more intuitive to add a page from the current > > > page, > > > > so > > > > > > in > > > > > > > > the > > > > > > > > > current location, instead of the "black bar that gives the > > > > > > impression of > > > > > > > > > not beeing a part of that page" (that she did not manage to > > > find > > > > by > > > > > > > > > herself). > > > > > > > > > > > > > > > > > > I then explained that the buttons inside the page only > concern > > > > the > > > > > > > > actions > > > > > > > > > that you can do on that page, meanwhile adding a new page > > > should > > > > be > > > > > > put > > > > > > > > in > > > > > > > > > an other location. She did not like this logic :) > > > > > > > > > > > > > > > > So with this logic we should remove the top bar completely > and > > > move > > > > > all > > > > > > > > actions inside the page, i.e. have only 1 menu inside the > page. > > > > > > Because if > > > > > > > > she couldn’t find the Add button there she also wouldn’t be > able > > > to > > > > > > find > > > > > > > > all wiki-related actions, space-related actions and more > > > > importantly > > > > > > > > **page-related** actions like copy page, rename page or > delete > > > > page… > > > > > > > > > > > > > > > > Also would be fun to ask your wife to try using Confluence > and > > > see > > > > if > > > > > > she > > > > > > > > fails to create a page there too. > > > > > > > > > > > > > > > > Thanks > > > > > > > > -Vincent > > > > > > > > > > > > > > > > > Users' logic and developer's logic are not the same. I > like the > > > > > > current > > > > > > > > > location too, except that we should propose "create page" > > > before > > > > > > "create > > > > > > > > > wiki". > > > > > > > > > > > > > > > > > > I really would like to have some feedback of normal users, > with > > > > > the 2 > > > > > > > > > proposals. We, as developers, are not good at making things > > > that > > > > > look > > > > > > > > > simple for other people, so we should not take this > decision > > > > alone. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Guillaume Delhumeau