9 Oct
2014
9 Oct
'14
2:17 p.m.
Now, regarding the actual problem:
We have been doing this for years and years, our users are used to this
(clicking on the top entry) and everybody was fine with it. Now we want to
perform 2 clicks instead of 1. Why?
Where are the jira issues and the user list emails complaining about our
current way of doing it? More so, where are the complaints about doing the
same thing in Flamingo? There's not even a proposal on this topic, just
this brainstorming that has "stormed" right to implementation. Don`t get me
wrong, I`m not asking for a proposal or approval of every minor thing we do
to the product, but this type of things are very high profile and I don`t
like to see (seemingly) random implementations and/org partial or rushed
solutions without agreement on the topic.
P.S.: Having a better look, it seems that the "non-standard bootstrap
dropdown buttons" are actually standard bootstrap dropdown buttons. The
only non-standard thing about it is us using them in the top navigation
section.
Thanks,
Eduard
On Thu, Oct 9, 2014 at 3:00 PM, Eduard Moraru <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.
Thanks,
Eduard
On Fri, Oct 3, 2014 at 4:21 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
On Wed, Sep 24, 2014 at 5:25 PM, Ecaterina Moraru
(Valica) <
valicac(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <vincent(a)massol.net>et>:
>
> > 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