21 Oct
2014
21 Oct
'14
11 a.m.
On Thu, Oct 9, 2014 at 5:59 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (jeremie.bousquet(a)gmail.com
(mailto:jeremie.bousquet@gmail.com)) wrote:
I think it's not bad to have a slightly different behaviour for desktop and
mobile. I don't have much experience with this but I think that we should
not ruin desktop experience because it has to work on mobile. If different
behaviour is the solution, let's do it.
I think the old behaviour with the hover was quite natural, and the fact
that bootstrap does not have those buttons by default is because it's
mobile first. But, as much as we'd want it, XWiki is not yet mobile first
(I would say most of the usage of XWiki today is still desktop, but since I
don't have statistics I cannot prove it. I can only use my personal
statistic, from my experience and the cases I know).
2 clicks feels completely unnatural on desktop, especially when coming from
colibri.
I would not want to let Bootstrap kill our UI choices, I think it's the bad
reason to say that "we won't do it because bootstrap does not have a
default component for it".
Thanks,
Anca
Hi,
In fact, colibri top-menu was better than bootstrap buttons ! :D
Why not putting back old ways of interacting ?
- re-add display of dropdown menu on hover [1]
- re-add underlining on hover of links in menu text
The reason we changed that was for mobiles. We could decide to have
different behaviors on mobile and desktops but not sure it’s best. WDYT?
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
Problem I feel is for second item as it seems
bootstrap won't easily
allow
you to hover on something (for dropdown) and
click on it (to do something
else than show dropdown). Also I suppose there are impacts on mobile
version.
I don't think the new flamingo way is bad, but visually it looks very
similar to colibri (a text + a little triangle), but when you hover
nothing
happens, and you have no visual clue that
something different may happen
if
you click on the text or on the triangle. For
example take the "New"
button
in Outlook 2007 which is exactly a dropdown
button, when I hover on it I
see a clear separation between the "New" text, and the arrow, so I can
assume that both lead to different results.
With the "Add" and "Edit" buttons it's completely different, you
see the
separation, and on hoovering the color changes (of the text OR of the
arrow
background). You are prepared to the fact that
something different will
occur.
But doing the same in top menu would clearly not fit expected look&feel
of
this beautiful skin...
BR,
Jeremie
[1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
2014-10-09 16:02 GMT+02:00 vincent(a)massol.net :
>
>
>
>
>
> On 9 Oct 2014 at 14:23:49, Eduard Moraru (enygma2002(a)gmail.com(mailto:
> enygma2002(a)gmail.com)) wrote:
>
> > On Thu, Oct 9, 2014 at 3:15 PM, vincent(a)massol.net
> > wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > On 9 Oct 2014 at 14:02:05, Eduard Moraru (enygma2002(a)gmail.com
(mailto:
> > > enygma2002(a)gmail.com)) wrote:
> > >
> > > > 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.
> > >
> >
> > "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?
>
> 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
>
> > Thanks,
> > Eduard
> >
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > 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
> _______________________________________________
> 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