incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: Bloodhound UI basics
Date Fri, 03 Feb 2012 13:11:44 GMT
> [...]
> ... so please let's focus on these screenshots [4]_ [5]_ so as to
> compare them with the idea sketched in previous wireframe (link above
> ;) . afaics changes needed (top-down taking wireframe as a reference
> ;) are the following :
>
> 1- Remove project name + description ? Or that part was just skipped ?

I'm not sure where this was shown previously?
Maybe the idea is a bit more clear when it includes what it would look
like once in full flow, with multiple projects set up, etc:
http://dl.dropbox.com/u/59840506/Bloodhound/Mockups/tickets_dashboard.png

I haven't sent this before as I'm not sure yet if the lift of projects
should be above or below the list of tickets for example.. But I may
as well post it for discussion. I would personally say that testing
the alternatives is the only way to get a good answer to this.

> 2- Keep only login / logout items in metanav + a drop down menu
>     displaying the rest (i.e. Settings) .
>     I think It's necessary to mention up to this point
>     that (IMO) metanav != settings . AFAICS preferences (one item in
>     metanav ;) ≃ settings ;) ; hence clarification needed
>     btw metanav in screenshots was based on GMail look and feel .
>     * Is it ok ?
>     * Should I keep it high like in screenshots or closer to
>       the metanav ?

What's called settings in the mockup can be changed to preferences,
that's not a problem.
In terms of that being a dropdown, GMail actually only gives you
display density settings to choose, then just links to the actual
settings page. I think we'll be fine making settings/preferences link
straight to the appropriate page for now.

> 3- Move search + quick create ticket button to the left

Yes :) This is mainly because they are the main navigational elements
and most content that people frequently interact with will also be
close to the top / left area, that minimises the distance you'd have
to travel from navigation to content.

> 4- Suggestion : In search box add a drop down menu looking
>     like an icon so that users will be able to select the filter(s)
>     they'll use to search for the information they want
>     (i.e. make that magic happen when clicking on search
>     icon inside search box)

The way GMail makes filters accessible from within the search box is
very good. I do think the Search button to the right of the box is
needed as well though (GMail chooses a magnifying glass for that).
People scan pages for the word Search and omitting it would make it
less obvious where to search.

> 5- Use tabs for mainnav rather than the menu ?
>     If this is the case how submenus (customizable using
>     plugins) will look like ?

Submenus would queue items to the right of where it says Reports in
the top right corner, up until 3/4 plugins are shown, then provide a
"More" dropdown with the rest. I'm happy to provide a mockup for this
later / Monday if that sentence doesn't make sense :)


> 6- Add a tabs carousel (just like shown in screenshots). This
>     one should be a MUST due to the fact that overflow in
>     metanav MUST be controlled . This might happen due to :
>     * small screen dimensions
>     * small windows size (maybe even if it's resized after
>       web page is rendered)

By carousel, do you mean what's displayed with the buttons where the
mouse hovers in this image?
https://plus.google.com/photos/118444449354330048631/albums/5704585989523271585/5704588538735269650

In that case I have to say I'm strongly against the carousel. As a
method of dealing with 'overspill', ie too many items, this can work
in media / product libraries where you essentially discover options,
often serendipitously. Here it could lead to major navigational items
to not be visible, because they were first in the list and the user
has scrolled too far right. When that happens the next step would
always be frustration.

A dropdown called 'More' if plugins where already listed next to the
navigation once a certain number of items is reached, or better a
Plugin dropdown that contains all of them, is a better solution from a
usability perspective.

> 7- Add breadcumbs nav in top-left corner

Yes, within the tabbed area, because this isn't shared between the
tabbed things, and can stay persistent within each tab.

> 8- Insert ctxtnav menu in top-right corner (instead of previous tabs)

I'm not sure what you mean by this.. context nav, as in Ticket/Wiki/Source?

> 9- Activity column won't be part of the theme ... unless stated otherwise

I understood your first reply to this thread as saying that it would
have to be part of the theme?

> 10- Modify footer

I haven't put much thought into the footer yet, its seems fine the way
it is currently.

> 11- Add support to customize theme colors . This is a built-in feature of
>    ThemeEnginePlugin btw , so ... no big deal .

Not sure this is an important function. I would not implement this
unless users ask for it. I think we should just go with the Bootstrap
defaults for now. We don't have to use every feature that is available
straightaway :)

>
> Please I'd appreciate if you could review the TODO list above and cmiiw
>
> [...]
>
> General considerations used to build the theme :
>
> 1- control scrolling using a div inside the web page
>     (<= therefore nav items are always at hand ;)
> 2- make it work for 640 x 400 resolution [2]_ [3]_
>     (this one was taken before starting this thread ;)

Which devices to you envisage with such a low resolution? I can only
think of phones/tablets, where actual size is much more important than
resolution - as an example when the resolution was doubled with retina
displays in iphones, buttons stayed the same size because the critical
thing here is actually the size of your finger, not the pixels.

> 3- use jQuery-UI CSS [6]_ as much as possible
> 4- maybe some others ... I'll mention once I recall ... ;)
>
> PS: For further screenshots (at different points in development
> process) the whole album [1]_ should be publicly available . I hope
> you all can see it .

Yes, I can see them.. We should try to get them into the Bloodhound
SVN system as soon as possible though, rather them host them
externally.

- Joe

Mime
View raw message