Another thing to consider: if we alter the global menu, than we will need a new skin IMO. I'm not saying that should be Macaw, but maybe another version of Flamingo.
We would need to modify some than a couple of templates. We already changed the menus behavior in Flamingo like 2 times (with the 'Add' button, then with the 'Go to' functionality). Where do we consider the changes are vast enough in order to need another skin? Thanks, Caty On Tue, May 26, 2015 at 11:46 AM, Ecaterina Moraru (Valica) < [email protected]> wrote: > Hi Vincent, > > The iteration follows two ideas: > A. combine the global menu functionality with breadcrumbs (this was again > suggested by you when we proposed Macaw skin); > B. use trees inside the breadcrumb; > > I've iterated on A) in order to demonstrate how it will look like, what > problems/confusions might appear. > My conclusion is that combining the 2 functionalities will increase > complexity and cause either harder navigation or confusion (depending if we > display or not the entity icons). The solution could be to keep the > breadcrumb for navigation, while transferring the global-menu actions > inside the content-menu (but this ideally needs to be adaptive - which is > again not that straightforward to implement) + Drawer. > > I've iterated also on B). The usage of tree depends on how many entries we > plan to display in the breadcrumb (3, 5+, etc.) in order to provide added > value by tree usage. This direction could have further iterations if we > want to go this way, like: > - provide also actions inside the Tree displayer (still actions needs to > be limited + plus think about mobile usage); > - have a common activator (we could use the Home icon) or localized tree > activator (the mockup displays a localized activator on '...'); > - other? > > Some questions that appeared during this iteration: > - what do we do with the parent/child backwards compatibility? > - when we have nested spaces, we display the space or the space.webhome? > the type of the entry is a space or the page? > - how important is to limit the breadcrumb display? usually how many > entries we have in a breadcrumb? Should we default for more than 7 entries > or keep 3 like we currently have? > - how important is to provide fast access for Watch or Delete space > actions? or other actions inside the global-menu? Administration and > Indexes could be displayed in the Drawer, Watch+Delete inside the > content-menu ( > http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin#HGlobalMenu) > > Compared to other proposals (when the 'final' solution was presented), > here it was mostly an iteration, exploring possible approaches and > requesting feedback or other ideas. > > Thanks, > Caty > > On Tue, May 26, 2015 at 11:02 AM, [email protected] <[email protected]> > wrote: > >> Hi Caty, >> >> On 22 May 2015 at 17:39:58, Ecaterina Moraru (Valica) ([email protected] >> (mailto:[email protected])) wrote: >> >> > Hi, >> > >> > This is an iteration for: >> > Extended-Breadcrumb's purpose is to provide a solution to *combine* the >> > global-menu functionality with the current breadcrumb functionality, >> while >> > supporting *nested spaces* concept and being backwards compatible with >> > *parent/child* relationship. >> > >> > Proposal: >> > http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb >> >> It’s cool that you started working on this! :) >> >> However I don’t understand the conclusion. You say: >> “The recommendation is to keep separate the navigation (breadcrumb) from >> entity type actions (menus).“ >> >> However the 3 screenshots don’t reflect that since the entity type action >> have disappeared! >> >> Could you explain what’s your proposal for the entity type action menu >> and how you implement nested spaces in it? >> >> Thanks >> -Vincent >> >> > Thanks, >> > Caty >> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
