9 Oct
2014
9 Oct
'14
4:02 p.m.
On 9 Oct 2014 at 14:23:49, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
On Thu, Oct 9, 2014 at 3:15 PM, vincent(a)massol.net
wrote:
The problem I saw is that users were not clicking the arrow but the main button part (thus
navigating instead of having the main options).
What we want is that it’s the simplest possible for the user for his use case at hand:
- When I click Edit or Add (not the arrow, the button) it’s the simplest possible. Edit
will choose the good default mode and add will add a page
- When I click the wiki/space/page button (not the arrow) I want the actions to be
displayed rather than the navigation since navigation is a secondary use case for these
buttons
At least that’s how I view it.
Forcing the user to have 2 clicks to do the main action on a button would be a pity.
Now you’re going to say that we could keep the arrow for the wiki/space/page buttons to
navigate. We could, but it doesn’t feel natural.
What do you suggest?
Thanks
-Vincent
On 9 Oct 2014 at 14:02:05, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
"It seems they either don’t understand the little triangles and what it’s
about (submenu?) or they click on the menu itself and go to another page
when they were expecting some menu to drop down, or.."
There is no difference from the "problem" you have mentioned in the OP. The
user sees an arrow and clicks on the button to expand the menu, but instead
ends up reloading the page (either to edit mode or to view mode, same
thing). You will say that he wanted to edit anyway, yes, but maybe he did
not want to edit in the default mode, so the user's "intent" (as you
defined it in the OP) is still not respected.
We either do it one way, or the other, all I ask for is consistency. Do we
want to introduce yet another compromise in this young skin? Folks, you speak of consistency and then come up
with this solution...
So we have a problem with "non-standard bootstrap dropdown buttons" that
our users (whoever they may be) have a problem with understanding that
there is either an action or a dropdown involved in the same button, like
they can encounter in other interfaces along their computer usage
history.
Our solution is to stop using the mixed mode, and only use the "standard
bootstrap dropdown buttons" that have their first action in the submenu
the
thing that would have happened in the past when
the users clicked
directly
the action part of the "mixed button"
we were using.
Ok, we implement this solution, but we only do it for the top
navigational
elements. We completely ignore the
"Add" and the "Edit" buttons that
"suffer" from exactly the same "problem".
My question is: why?
If we do/did decide that this is the way to go, we should at least be
consistent and do it everywhere in the UI, otherwise it just causes
frustrations.
There’s a difference. For the Edit/Add button click the button will do
what the user wants. Click the arrow is only for advanced featurs.
Thanks,
Eduard
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Thanks,
Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) > > wrote:
> On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com> wrote:
>
> > Hi,
> >
> > Some background:
> > * Colibri
> > ** menus displayed on hover
> > ** custom menu JS
> > ** menu entries could be icon+label+separator+link+whatever
> >
> > * Flamingo
> > ** menus displayed on click
> > ** menu component from Bootstrap
> > ** it expects simple links or menu dropdown containers (not both
> functions)
> >
> > Theoretically Bootstrap doesn't support our use case and cannot
replicate
> > by default the Colibri's behavior.
> > Any change we want to make to the menu Bootstrap component means we
are
> > branching from the default behavior and
we will create a custom one.
> > We really need to listen to clicks and not hover state, since we
need
to
> > be mobile compatible.
> >
> > It's normal that the users feel a bit confused since they are used
with a
> > certain behavior and we tried to mix
them in order to have both menu
and
> > navigation use cases.
> > And I think the reason is a bit confusing is that the separation
between
> > the link and the arrow is invisible,
compared with the btn-groups
used
> for
> > Edit or Add. For example, I think that making the separation more
clean,
> > like in this screenshot
> > http://jira.xwiki.org/secure/attachment/28807/btn-group.png would
> improve
> > a bit the things, but would need visual improvements and is not
default
> > also. Maybe we could think of a better
solution if we were to go on
this
> > path.
> >
> > Behavior like double clicking a certain element will be a hidden
> > interaction for the users. Double clicking is not a Web behavior and
you
> > cannot expect users to know on which
links to simple click vs. on
which
> to
> > double click. In the usability testing sessions users had a hard
time
to
> > double click on uploading image in the
WYSIWYG popup, so I'm not sure
> about
> > this approach's success.
> >
> > Regarding the IntelliJ IDEA screenshot, we already discuss about this
> idea
> > and even made a similar proposal some long time ago, see
> >
http://design.xwiki.org/xwiki/bin/view/Improvements/ActionMenuNavigation
> > Although this proposal is a nice idea
and I would like to have it, I
> don't
> > see how this would 'simplify' the current implementation. IMO it will
> make
> > it even more complex and we would certainly need a custom menu. Also
I
> see
> > this as a new feature, than a solution to our current problem.
> >
> > When we implemented the current solution we discussed if the
navigation
> > should be put on the text or on the
icon, see
> > http://jira.xwiki.org/browse/XWIKI-10449 . The main problem is the
> > findability of this functionality. Users might never press that icon
> (this
> > problem applies to the solution brainstorming and the breadcrumb
> proposal).
> >
> > So I think the idea to have an entry with "Go to ..." could be a
solution
> > and to keep the menus interact with the
default behavior (removing
the
> > navigation from the dropdown
activator).
> > Removing triangles is not an option. That is a default menu marker
caret.
> >
> > So what are the next steps? We do a issue with the "Go to ..."
solution?
> >
>
> http://jira.xwiki.org/browse/XWIKI-11166
>
>
> > Thanks,
> > Caty
> >
> > On Wed, Sep 24, 2014 at 11:55 AM, Guillaume "Louis-Marie" Delhumeau
<
> > gdelhumeau(a)xwiki.com> wrote:
> >
> >> Hi.
> >>
> >> I am happy that this topic is coming back.
> >>
> >> 2014-09-24 10:04 GMT+02:00 vincent(a)massol.net :
> >>
> >> > Hi devs,
> >> >
> >> > I’ve had a few persons tell me that they don’t like the small
arrow in
> >> the
> >> > top level menu in Flamingo. It seems they either don’t understand
the
> >> > little triangles and what it’s
about (submenu?) or they click on
the
> >> menu
> >> > itself and go to another page when they were expecting some menu
to
> drop
> >> > down, or...
> >> >
> >>
> >> I don't like it neither. It is not consistent with other projects
(such
> as
> >> JIRA). It is not consistent with what we are planning to do about
the UI
> >> language (see:
> >>
> >>
>
http://design.xwiki.org/xwiki/bin/download/Proposal/InterfaceAndContentLang…
> >> ).
> >> It is harder to use on mobiles, and people are surprised by what
occurs
> >> when they click on it.
> >>
> >>
> >> >
> >> > In addition we’re still missing a solution to easily navigate the
wiki
> >> > from any page (there’s the
ctrl+G solution but this is more like a
> >> shortcut
> >> > to know and we need something more).
> >> >
> >> > So here are some ideas:
> >> >
> >> > * For the top level menu, make it simpler by having the drop down
> >> display
> >> > when you click anywhere in the menu (the whole width of it) and
only
> >> > navigate when you double click
(there are actually few reasons to
need
> >> to
> >> > navigate with the other idea below so we could also not do the
double
> >> click
> >> > thing)
> >> >
> >>
> >> +1
> >>
> >>
> >> >
> >> > * In the breadcrumb OR in the top level menu OR in both (to be
> decided)
> >> > use something like this (screenshot taken from IntelliJ IDEA):
> >> >
> >> >
> >>
>
https://www.evernote.com/shard/s119/sh/20e99ab3-2991-4aa8-a7b5-93088aad4944…
> >> >
> >> > This means when you click at a given level you get to see all
sibling
> >> > elements in the wiki for
element you’re currently on (document,
space,
> >> > wiki).
> >> >
> >> > For example clicking on the “Home” wiki would show:
> >> > - A filter box allowing you to type and it would auto suggest as
you
> >> type,
> >> > completing with wiki names
> >> > - An icon would be displayed on the left (or on the right) of the
> filter
> >> > box and if you click on it you’ll go the index page (Wiki Index in
> this
> >> > case)
> >> > - A list of the first 10 wikis (an improvement would be to list
first
> >> the
> >> > wiki that you’ve last navigated to)
> >> >
> >> > Same would apply for spaces and pages.
> >> >
> >> > We could even imagine that when you’re on a user profile page,
> clicking
> >> on
> >> > it would display other user pages and the filter would filter on
user
> >> > pages. Actually we could
imagine to when the current page has
XObjects
> >> in
> >> > it, it would be possible to list all other pages in the wiki
having
> the
> >> > same XClass. And if there are several XObjects, then somehow in
the UI
> >> > allow selecting which one to
consider as the filter criteria.
> >> >
> >> > * Note 1: The breadcrumb is currently not displayed on all pages
(it’s
> >> not
> >> > on the home page for example) and thus if we implement this idea
in
> the
> >> > breadcrumb only then there’s no solution for navigating on the
home
> >> page.
> >> >
> >>
> >> This is a behaviour that I have put because I thought it was not
pretty
> to
> >> have a useless breadcrumb on the home page. It can be changed.
> >>
> >>
> >> >
> >> > * Note 2: If we were to implement this idea on the top level menu,
> then
> >> we
> >> > still need to display the actions too. Several options:
> >> > - a) Display the actions first and the navigation list after
separated
> >> by
> >> > a -----
> >> > - b) Have a first entry in the drop down that says “Actions...”
and
> when
> >> > you move the mouse over it a secondary menu with all actions are
> >> displayed.
> >> > Note that the alternative is possible too: Display the actions and
> have
> >> a
> >> > “Go to..." menu entry. We would just need to choose to display
what we
> >> > think is the most used default
(actions or navigation)
> >> >
> >>
> >> +1
> >>
> >>
> >> >
> >> > WDYT?
> >> >
> >> > Personally I would do this:
> >> > - implement this idea for the breadcrumb
> >> >
> >>
> >> +0, I need to think more about it
> >>
> >>
> >> > - add “Go to wiki...”, “Go to space...", “Go to page..."
menu
entries
> in
> >> > the Wiki/Space/Page top level menus
> >> >
> >>
> >> +1
> >>
> >>
> >> > - expand the menu selection to the whole width for displaying the
drop
>>
> down (and not just above the small arrow)
>> >
>>
>> +1
>>
>>
>> > - either support double-click or simply add the possibility to
navigate
>> to
>> > that element in the “Go to xxx...” submenu
>> >
>>
>> +1
>>
>>
>> >
>> > Thanks
>> > -Vincent
>> >
>> >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>>
>>
>>
>> --
>> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs