From: Dylan J. <dj...@pr...> - 2015-05-26 04:13:13
|
> On 26 May 2015, at 10:49 am, Nathan Van Gheem <na...@va...> wrote: > > I'd also like to consider not shipping with the option to have it horizontal AND vertical. We should probably just default to supporting one well thought out mode. Vertical and Horizontal menus have their ups and downs... :) I tend to agree make one work really well is better Just for background, I was the person who originally suggested the vertical menu and the reason was not so much for UX of the editor but because we were using absolute positioning and it was really easy to overlap another absolutely positioned top menu. The idea was that people are less likely to use an absolutely positioned side menu so it was less likely to get in the way of the theme. So really it was solving a UX problem of themers. ie make it work with the most amount of themes without modifications. > > On Mon, May 25, 2015 at 10:34 PM, Dylan Jay <dj...@pr...> wrote: > > > On 26 May 2015, at 2:26 am, Nathan Van Gheem <na...@va...> wrote: > > > > HV, > > > > Well, this particular issue isn't momentum killing. We are aware of it--just no one has figured a decent solution yet. > > More people talking about it and thinking about it is helpful though :) > > > > I'm not sure I agree with you on the vertical. I actually enjoy using the left side variant. > > > > Dylan, > > > > We aren't using hover menus. You need to click to open. > > sorry you are right, its not hover. however one issue with a vertical menu is that the popout now requires to you go down, click then go back up. You end up travelling a lot and doing a uturn with your mouse which isn't so nice. > Looks like hectors points are mostly about making current status visible. > Yes, this causes you to provide things in more clicks often to prevent the uturns which power users usually don't appreciate. > > I have a couple of ideas which I'll find the right tickets to add them to but quickly (no need to respond). > - One option would be to change it from a multiple submenus to a single extra ribbon/menu that you can expand and keep open. So the menu has 3 modes. icons, icons text, icons, text and extra menu. That could solve some of hectors concerns of not seeing stuff and also my concern of the mouse uturn. > Yes, I've thought of this idea too. Additionally, the text + icons could be stacked on top of each other so they take less horizontal space. > > Really, we could just implement some of what the old CMSUI had... It took up too much vertical space but kind of did what you're talking about. I'm interested... We'd really have to see how much stuff is on the menu. and we can't control it since it's going to plugin added actions and tabs. Maybe if need be it can open out again if its too long? > > - It does however create another problem of having still too much stuff in this combined extra menu. I think we can aid in that by getting rid of the display menu. I believe this should now be a popup with a post request. We see a lot of issues around people not understanding display enough and I think it needs more text and explanation around it which we can do in a popup. I think the same is probably true of the state menu. I think its something that you don't do lightly and should be a popup. If you want to do it in bulk you can do it via contents. > I agree about display, not about state menu. I think a lot of users would be annoyed by the extra clicks required just to publish an item. maybe. but its not that much extra clicks if state was moved to the top level (and showed current state) then you click once to display the overlay and once to pick the state and once to save. So 3 clicks instead of 2 but in the process we can have the ability to display a long description of what a transition means which would help usability for beginners. If you get rid of the save button then its the same number of clicks. And we already have the overlay so no extra work. I'll tell you story about POST vs GET for these menus. We wrote a checker that tested all the links on our main pages. We miss configured so permissions once such that connections from localhost had admin access. Suddenly our homepage was not the default page anymore and it was unpublished. Really, anything that changes the DB should really be a POST. > > Also, State *could*(maybe should) be added to the edit form(please don't yell). +1 > > - the other option is an open close accordion type menu. More similar to normal side navigation. There is a reason side nav is not popout but rather open/close. If the menu remembers which are open and closed you can effectively configure the menu to keep visible parts you are using often such as the add menu or the context status. > > > > > > Yes, doing something with the icons could work though! > > > > The menu isn't really responsive right now either. No matter way, when on mobile devices, it'll need to be swipe out on the left or right I think for mobile. > > > > > > > > -Nathan > > > > On May 25, 2015 2:15 PM, "Hector Velarde" <hec...@gm...> wrote: > > On 05/25/2015 02:00 PM, Nathan Van Gheem wrote: > > https://github.com/plone/Products.CMFPlone/issues > > > > HV> thanks! the first issue was already reported: > > > > https://github.com/plone/Products.CMFPlone/issues/411 > > > > Click the plone icon to total text. Click upper top left to move from > > side to top. > > > > HV> that was awesome! thanks! > > > > I think we need a control panel entry to set this on the site without > > using the theme. > > > > HV> +1 > > > > Yes, the way you go about things can be annoying and momentum killing > > but you can be helpful too. > > > > HV> sorry, Nathan; I don't want to annoy anyone and I don't want to kill your momentum... but at some point we need to face reality and we better do it before the final release. the horizontal toolbar should be the default, IMO; I haven't tested it in depth, but it has to be better than the vertical one. > > > > No, you're not the only one who notices. I also mentioned it during the > > UI/UX meeting. Most everyone that uses it knows it needs tweaking. There > > just isn't an obvious best way to do it where the toolbar actually fits > > decent widths when on top. If you know the perfect way to plan out the > > toolbar buttons, please share. > > > > HV> no, I have no idea on how to solve it; I'm not an UI/usability expert but the issues the vertical toolbar causes are screaming at me every time I have tested Plone 5. > > > > the one thing I want to bring back here is that, IMO, we made a mistake by skipping the 4.4 release; Plone 5 brings many UI changes that are not tested with real users before including them on the core and we are risking here too much. > > > > releasing faster with few changes and making some of these changes optional for power users to test first, give us feedback earlier so we can fix broken ideas faster also. > > > > that's the way we went with Diazo and Dexterity and it proved to pay. > > > > having said that, I can tell you that Plone 5 is looking pretty fine now; last time I tested it was one of the earlier alpha releases and can see a difference here. > > > > thank you very much for the hard work you guys have done! > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > > Plone-developers mailing list > > Plo...@li... > > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > > -- > Nathan Van Gheem > Solutions Architect > Wildcard Corp |