Suggested 'Reference' Mockups
Michael Heilemann
mockups. The January/February mockups in my flickr account, which are
referred to on occasion are all a bit out of sync with each other,
causing no doubt, some confusion. The reference repository would be
the final say on the subject, and further implementation would have a
an undisputed guide.
Over the weekend I dusted off and updated the mockups to reflect the
current state of Habari. The menubar is as suggested in
http://groups.google.com/group/habari-dev/t/8b7941ee041b5f89, as I
find it elegant, powerful and mom-friendly, which is worth fighting
for I think.
Enough talk, here are the mockups, with comments:
http://flickr.com/photos/heilemann/sets/72157603227434486/
If these are acceptable, I'll go about implementing them (to the
extent HTML, CSS and JS can make it happen), while also moving on to
bring other parts of the admin in line with the style.
PS: For further discussion of the menu structure, please keep it here:
http://groups.google.com/group/habari-dev/t/8b7941ee041b5f89
Michael Bishop
before, I also am strongly against a 710px wide container, though it's
hard to tell the width in these mockups.
The bells and whistles are nice, but I think a detailed outline of
what would be needed from a functionality standpoint to make some of
it a reality needs to be hashed out before hand.
You'll have to forgive some of us if we are feeling a bit of dejá vu,
but with that said, I'm excited to see how some of this would be put
into working code.
~miklb
On Nov 18, 4:55 pm, Michael Heilemann <heilem...@gmail.com> wrote:
> As mentioned on IRC earlier today, I sugges a repository of reference
> mockups. The January/February mockups in my flickr account, which are
> referred to on occasion are all a bit out of sync with each other,
> causing no doubt, some confusion. The reference repository would be
> the final say on the subject, and further implementation would have a
> an undisputed guide.
>
> Over the weekend I dusted off and updated the mockups to reflect the
Christopher Davis
personal aesthetic sort of thing? I would much rather have a fluid
layout if we could pull it off myself. Of course all of the monitors
I work on are widescreen, so I might not be the best person to give
opinions on this matter.
I definitely like the way the UI is going in these mockups and would
like to some markup to play with. I am a big fan of the re-orienting
of the menu items to the left side of the screen, but I am not too
keen on the removing of linkage straight to the user manual. What
might be interesting would be to have one link, that goes to the user
manual. In the opening text of the manual we link to other forms of
support if needed.
Just some stuff to think about.
Chris
Michael Bishop
On Nov 18, 5:32 pm, Christopher Davis <c...@chrisjdavis.org> wrote:
> Is there are technical reason against the grey, or is it more of a
> personal aesthetic sort of thing?
posted in issues, the general readability of the page seemed off. I
don't have the biggest monitor in the world, but I do tend to surf
full resolution, so @ approx 1200 x 850px of it was disconcerting to
my eyes and drown out focus on the container and content creation/
admin functions.
I would much rather have a fluid
> layout if we could pull it off myself. Of course all of the monitors
> I work on are widescreen, so I might not be the best person to give
> opinions on this matter.
> I definitely like the way the UI is going in these mockups and would
> like to some markup to play with. I am a big fan of the re-orienting
> of the menu items to the left side of the screen, but I am not too
> keen on the removing of linkage straight to the user manual. What
> might be interesting would be to have one link, that goes to the user
> manual. In the opening text of the manual we link to other forms of
> support if needed.
discussion, so a single link to the manual would suffice. Otherwise,
it would seem the manual would be lost to the user. Linking just to
the manual may stave off repetitive posts to either a forum or -users
for common issues that should be covered in the manual.
~miklb
Matthias Bauer
> Over the weekend I dusted off and updated the mockups to reflect the
> current state of Habari. The menubar is as suggested in
> http://groups.google.com/group/habari-dev/t/8b7941ee041b5f89, as I
> find it elegant, powerful and mom-friendly, which is worth fighting
> for I think.
>
> Enough talk, here are the mockups, with comments:
> http://flickr.com/photos/heilemann/sets/72157603227434486/
>
> If these are acceptable, I'll go about implementing them (to the
> extent HTML, CSS and JS can make it happen), while also moving on to
> bring other parts of the admin in line with the style.
I'm in favor of limiting the width of the admin for the reason you gave,
that text just becomes unreadable when the lines are too long. I am also
very much for moving the menus to the left, because that's where they
*should* go, both from experience with all other UIs and from a cultural
background (for LTR locales).
How would the tab order look on the create content page with any of the
tabs expanded? Would the settings panel get tab focus between tags and
the buttons, or after the buttons, for example?
Would it make sense to have Settings / Tags / Preview as collapsible
panels instead of one tabbed pane, so more than one of them can be shown
at the same time?
Field labels inside the fields ... not good IMO. The description
vanishes the instant I want to actually USE the field. That just seems
wrong to me. I see the stylishness though.
The footer should have 'Manual' and 'Support' links, I would think, but
I can also see the reasoning for a single support landing page. Anyone
care to weigh in on this?
Minor nit: I'd go with a lighter grey in the background to enhance contrast.
Apologies if this comes off as negative, I like the mockups quite much
and I like your intention of actually making them into HTML even more.
Please do not be put off by my quibbling ;)
-Matt
Michael Heilemann
Matthias Bauer
> If we're talking what needs to be done to specifically implement these
> mockups, then here's a list as I see it:
>
> - Updated Content/Admin Menu
> - Updated HTML and CSS (obviously)
> - Page-splitter JS (for the tabs)
> - Input/Textarea JS
> - Fallbacks for both JS solutions
>
> All of which I can write, with the exception of the recajiggered menu
> (give me a few days, and I'll see what I can do ;).
Owen hacked up a JavaScript thing to only move the labels 'into' the
fields when JS is enabled. That seems sane and may be useful for you
here, too.
>> How would the tab order look on the create content page with any of the
>> tabs expanded? Would the settings panel get tab focus between tags and
>> the buttons, or after the buttons, for example?
>
> I personally think the tab order should always be Title > Content > Tabs
> > Publish. Whatever comes after that is fine, but since the finest job
> of Habari is to publish things, it should be as easy as possible.
What do you think about moving the buttons above the splitter?
>> Would it make sense to have Settings / Tags / Preview as collapsible
>> panels instead of one tabbed pane, so more than one of them can be shown
>> at the same time?
>
> In essence, it probably would. I don't personally like it, as it means
> more clutter than necessary. But it could work, no doubt.
Help me think here ;) You have the idea how the UI would work.
Would several of the panels be used at the same time? Often enough to
warrant more clutter vs. easier UI?
>> Field labels inside the fields ... not good IMO. The description
>> vanishes the instant I want to actually USE the field. That just seems
>> wrong to me. I see the stylishness though.
>
> I see the sentiment, and obviously the semantic structure should be
> intact behind the scenes. But practically, you learn the
> title/content/tags setup the instant you first arrive to the Create
> Page. And you're reminded on every subsequent return.
>
> By removing the title h2's (or whatever), the focus is as much on your
> content as possible, and I very very much like that idea (see the WP
> create screen for how _not_ to do it!).
That's a good point, and together with the JS mentioned above that only
removes the labels if JS is enabled, keeping the semantics alright, I
think I'm ok with this.
-Matt
khaled Abou Alfa
Nice work all around. I really like this, just some thoughts:
1. Although I'm not completely keen on moving the drop down menus, I can see the reasoning, it just looks a bit odd to me personally.
2. Not so keen on the height of the bar at the top, but alas what else is new :).
3. Still need convincing on the limitation of the drop down menus to two elements only as I feel the number of items on these drop down menus is excessive. But again the proof is in the pudding really. While the admin doesn't look too bad, the Content menu has got too much going on in there. I don't know if we're making things more complicated by trying to streamline everything.
4. I like what you've done with the drop down menus having a shadow and rounded corners as well.
5. I like what's going on in the settings menu. Works well with the as yet not done image/content uploader. Nice to see consistency in the design (something I have a major pet peeve about, when things don't go well together).
Other than the third point which I really think we should have more discussions about, no complaints from me, go forth and conquer my son.
Michael Bishop
On Nov 19, 2:41 am, "Michael Heilemann" <heilem...@gmail.com> wrote:
> The column width is 790px, which IMHO should be enough to serve the rest of
> the admin, and small enough to ensure that lines do not become so long as to
> be unreadable (which is currently the case, at 960px)
columns. Currently in trunk the publish page is using a span-18
column for the content box, which is 710px (with span-3 columns
appending and prepending ). So the container may be 950px, but the
content is 710. Are we saying the same thing in a different way? :-D
Most of the other pages are using a span-22 (870px) with a single span
prepending and appending.
> > The bells and whistles are nice, but I think a detailed outline of
> > what would be needed from a functionality standpoint to make some of
> > it a reality needs to be hashed out before hand.
>
> If we're talking what needs to be done to specifically implement these
> mockups, then here's a list as I see it:
>
> - Updated Content/Admin Menu
> - Updated HTML and CSS (obviously)
> - Page-splitter JS (for the tabs)
> - Input/Textarea JS
> - Fallbacks for both JS solutions
>
> All of which I can write, with the exception of the recajiggered menu (give
> me a few days, and I'll see what I can do ;).
that has a fall back in place for no-JS. It is in trunk now.
> Whatever the case, I think the goal is to make it a one-click 'Help' link
> for the user. Besides, haven't a 'help portal' is a good idea for when a
> resource is added, removed or moved (rather than having hard-coded links in
> 100.000 Habari installs).
should serve to be relevant enough to the version the user is running,
and does have links to the other resources. It has been a primary
goal to have the shipped docs with all installs, and without having
this link, users may not know there are there. At the time of .3
release, it contained as much info as the wiki for the end user.
~miklb
Michael Heilemann
Just so I'm on the same page as you, the grid is 950px, with 24
columns. Currently in trunk the publish page is using a span-18
column for the content box, which is 710px (with span-3 columns
appending and prepending ). So the container may be 950px, but the
content is 710. Are we saying the same thing in a different way? :-D
Most of the other pages are using a span-22 (870px) with a single span
prepending and appending.
As Matthias mentioned, Owen wrote some JS to do the input/textarea JS
that has a fall back in place for no-JS. It is in trunk now.
Certainly the manual won't be completely up-to-date, however, it
should serve to be relevant enough to the version the user is running,
and does have links to the other resources. It has been a primary
goal to have the shipped docs with all installs, and without having
this link, users may not know there are there. At the time of .3
release, it contained as much info as the wiki for the end user.
Michael Heilemann
Chris J. Davis
And if you need some help getting the rest of the way, I am sure
there are some people here would be more than willing to help.
chris
Michael Heilemann
with the patch, two new files and an outline of what was done and what
isn't working yet.
Hope ya'll like it :)