Habari Media Manager Sketch

Alright, I wasn’t planning on posting this just yet, but since I won’t have proper time to work on it for the next few days, my lack of patience got the better of me.

Now it is important to note that this isn’t even a mockup as much as it is a sketch (albeit rather a polished one). There is some functionality missing and so on and so forth.

First up is the edit page with the media manager closed. As you can see, I also put in Flickr and Youtube as similar services to hook into. However, the media manager itself is meant to be a way to manage your local files (images, video, audio primarily I think).

Habari - ClosedMedia Manager - Sketch

Click the My Media tab, and the page splits open, revealing the media manager underneath. The rest of the admin is obviously better off being centered and fixed width, but the media manager gets the benefits of ‘stretching from ear to ear’.

Habari - Open Media Manager - Sketch

A quick quick quick walkthrough of what I like to call a ‘feature-rich environment’:

  1. You can filter, sort and search your media library.
  2. Uploading takes place in the same area, I’m working on that stuff now.
  3. It is 100% of the browser width to give you more space.
  4. Like the textarea, you can resize the preview shelf, by grabbing the handle underneath the scrollbar.
  5. Double clicking a media preview, rolls out a small editing pane next to the image where you can edit title, desc. & tags.
  6. You add media to the content area by dragging and dropping.
  7. You should hopefully be able to preview audio and video. Audio is easy, video, not so much…
  1. There will be more stuff :)

And that’s what I’ve been up to in Habari. I’m pouring some of the stuff I work on into a flickr set, and of course both mine, Khaled’s and any other volounteers discuss all of this on the mailing list (and here is the thread for the above sketches).

And no, it won’t be coming to a Habari installation near you in the near future. In fact, I think I probably caused a few gray hairs in the Habari coders when they saw this. But it’s doable, and I’ll gladly chip in with my own meager skills.

Ideas, suggestions and what not are of course very welcome

15 Responses to “Habari Media Manager Sketch”


  • Very cool. Reminds me of the Flock web browser.

  • Whether or not they stay, those Flickr and Youtube buttons make me feel all warm and fuzzy inside.

  • Direct access to Flickr is a great feature which WP Admin lacks, although I’m sure I saw in Flickr’s TOS that you can’t use Flickr as an image host for your blog?

  • Michael, first of all, this is very lovely work. I like it a lot, and if this is an indication of what is to come for Habari, then it’s going to be great.

    First some quick thoughts on what I like. This is both design and usability feedback.

    1. I like the colors (or lack thereof). The blue in Wordpress is just overwhelming.
    2. I like the simplicity of things. As Charlie Chaplin said: simplicity is not a simple thing.
    3. I like the chromeness of things. UI widgets are usually gray on all platforms, meaning “gray and bevelled” is almost synonymous with “I can interact with it”. I’m especially looking at those lovely All / Images / Audio / Video button-tab things.

    Then some bad things.

    1. Where am I? What section is this? Is it the post page? How do I manage plugins, themes? (See elaboration later)
    2. Careful about styling those UI widgets. (See elaboration later)
    3. Careful about text contrast. The image titles seem quite dark, compared to the rest.
    4. This may just be slow backwater me, but I’d like to be able to choose something other than Flickr and Youtube as media channels.. maybe pluginify this and checkboxify this on the options page?

    Now for some elaboration.

    With regards to 1: I realize this is probably the Write page, and that plugins and themes and all that other mother jazz is probably tucked away in the admin menu. My point is, though, that while this is simple and nice, it might be a bit too spartan.

    Regarding 2: I’ve made your ears bleed with this already, and I won’t do it so much this time because a) my opinion has changed slightly, and b) since it is a mockup it is very likely you’re already thinking about this. BUT: be careful about styling UI widgets too much. By that I mean textfields, push buttons, scrollbars and so on. I’m especially looking at the scrollbar on the expanded media manager section.

    Bottomline is: Whatever you do, make sure it LOOKS like a scrollbar / textfield / whatever. I no longer despise styled widgets (though I still think it’s a bad idea), but just make sure people don’t have to learn new things in order to pick up the interface.

    I could go on with regards to tiny and completely insignificant design details, like the use of centering, or the use of textfield descriptions as textfield backgrounds and such, but I’ll let you chew on the other things first.

  • Thanks Joen, your comments are as always, very appreciated.

    The bad things:

    Where am I? What section is this? Is it the post page? How do I manage plugins, themes? (See elaboration later)

    The menu section is a discussion all of its own. It is a design that predates my involvement with Habari, but hopefully we can make it easy to use while still being out of view.

    Careful about styling those UI widgets. (the scrollbar in the media manager)

    Funny you should mention it, because I actually have a real scrollbar in my mockup PSD as well. But I think there might be some actual advantages for how the app would behave, by using a custom scrollbar.

    Also funny that you mention you have changed your mind slightly from when we worked on Shuttle. So have I, so I am very careful with widgets now :)

    Careful about text contrast. The image titles seem quite dark, compared to the rest.

    Yeah, I’m keeping my eye on that. But the idea was to make sure that the user would probably rely more on visual identification than on titles.

    This may just be slow backwater me, but I’d like to be able to choose something other than Flickr and Youtube as media channels.. maybe pluginify this and checkboxify this on the options page?

    It’s all plugins baby :) — So yeah, you can plug whatever you want in there.

    I could go on with regards to tiny and completely insignificant design details, like the use of centering, or the use of textfield descriptions as textfield backgrounds and such, but I’ll let you chew on the other things first.

    What is the problem with centering? As for the form elements, I knew you would mention that ;)

    Thanks dude. Any more you think of, shove it my way.

  • And my bq.‘s still don’t work. Dammit.

  • The menu section is a discussion all of its own. It is a design that predates my involvement with Habari, but hopefully we can make it easy to use while still being out of view.

    I can imagine. I trust it’ll rawk.

    Funny you should mention it, because I actually have a real scrollbar in my mockup PSD as well. But I think there might be some actual advantages for how the app would behave, by using a custom scrollbar.

    I’m glad I added soft of a disclaimer. Usually when a scrollbar looks overly styled it’s either iTunes 7 or Mac OSX. * ducks and runs for cover *

    Oh but seriously, I just wanted to reiterate it. I’m sure it’ll turn out fine.

    Also funny that you mention you have changed your mind slightly from when we worked on Shuttle. So have I, so I am very careful with widgets now :)

    Ah! Sounds great!

    With regards to my “transformation”, it’s really stuff for it’s own blogpost (which is actually in the works), but the gist of it is that with the advent of widgets, Google crossplatform apps, the great new Office 2007 ribbon UI and the general more liberal rules of game interface designs, I can see that styled UI widgets might no longer (with todays hires graphics) be as bad I’ve made them out previously. MIGHT not, mind you!

    What is the problem with centering?

    Well, the BENEFIT of centering is that you’ll have less problems porting Habari to RTL (Right To Left) down the road.

    The PROBLEM as I see it, is (as mentioned), insignificant, but simply a matter of “we start in the top left and end in the bottom right” – guiding the eye stuff.

    As for the form elements, I knew you would mention that ;)

    Again, insignificant, but just a minor worry that people looking for a textarea will be looking for a white inset blank area, not a white inset non-blank area. As I said, trivial.

    Thanks dude. Any more you think of, shove it my way.

    No problem, I will.

  • Joen:

    Re: form elements:

    I absolutely understand where you’re coming from. I would contend, however, that sometimes change is necessary to incorporate the user into a new way of looking at things. I mean, are the users that are going to use Habari going to be that illiterate? And if so, perhaps it’s a good thing that it’s being introduced.

    Designing for the lowest common denominator, much like what the movie studios do, is often times an insult to both groups, even if they say they “want” it like that.

  • Good for you, continuing to push the bounds of what we can and should expect from our software. This looks like it would be a real joy to use, and I can’t wait until there’s a demo of it somewhere!

  • [quote comment=“93242”]Joen:

    Re: form elements:

    I absolutely understand where you’re coming from. I would contend, however, that sometimes change is necessary to incorporate the user into a new way of looking at things. I mean, are the users that are going to use Habari going to be that illiterate? And if so, perhaps it’s a good thing that it’s being introduced.

    Designing for the lowest common denominator, much like what the movie studios do, is often times an insult to both groups, even if they say they “want” it like that.[/quote]

    I disagree with you completely.

    I fail to see how making a specially styled textfield with a GIF background is going to help me “do things in a new way”, that way being some groundbreaking new form of typing in content on a webpage.

    Not styling the form elements is not the same as designing for the illiterate. On the contrary, not styling the form elements is a form of respect for the end user, making sure that we’re not “inventing new forms of interaction” just for the heck of it.

    In my experience, the best interface is the one that goes unnoticed. As I wrote in an article a while back:

    Leaving things alone can be difficult for a designer. It’s in our nature to want to add our personal touch, to want to show how pretty things can be. Alas, making things pretty rarely means making them useful, so before breaking rules set out by precedents, we’d better make sure that there’s a damn good reason for doing so. If we do not, we run the risk of simply adding visual clutter, confusing and detracting from the result with every stroke of the brush. There’s a reason most spoons look alike; it’s a tested design and it works pretty well.

    Keep in mind, though: respecting functionality doesn’t mean we should simply perpetuate a design that we know works. Sometimes the formula can be improved upon and sometimes there’s simply no precedent. When this happens we need to rely on experience, gut feeling and extensive testing.

    In my experience a good interface design goes by unnoticed. I jump in and know how things work, how to go about my business. The cog-wheels of the engine beneath grind creak and turn exactly the way I expect them to. The badly designed interface, on the other hand, immediately stings my eye. I get annoyed that I have to learn how a particular feature works simply because the designer chose to “spiff it up” when I know things could’ve been different, simpler and more useful. In some cases I become reluctant or simply too annoyed to explore features. Even if the designer means well by touching things up, doing so might just tip the delicate balance of form and function.

    Now the reason I’m not reading this aloud to Michael (or Khaled for that matter) is because I have already discussed this with them, at length, they know where I stand, I know where they stand, and most importantly: I know they’ll do it right for Habari.

  • [quote comment=“93182”]…although I’m sure I saw in Flickr’s TOS that you can’t use Flickr as an image host for your blog?[/quote]

    You can, just have to be sure to link back to the original image. If you view all sizes for one of your own images you have a field that contains a links with the image inside for posting to your blog, they even say “Copy and paste this HTML into your webpage”.

    I’m not sure about using Flickr for images that are part of your page design though, especially since you would inherently not link to their Flickr page.

  • Joen:

    I guess I was a little off base with what I knew. I thought the text boxes just had pre-inputed text (with stylized font, of course) that disappears when you type into it. So I didn’t see how that was a big deal.

    Now, I think I hurried my reply a bit and therefore sounded a bit off. I am all for a good, clean, traditional UI. However, do we really need to have titles above everything, or to the side of everything to identify which piece is what. Is the end user that dumb or that stubborn, in that they can’t figure out what to input?

  • No worries, Kyle.

    And I agree, there’s not necessarily a need for text above, on the side or whatever. With regards to the text inside, as I mentioned to Michael, it’s a trivial detail, so I won’t really dive into it.

    If you want an example of a badly styled interface design, the type of design I was critizicing in my post above, look at the default Opera skin. The layout is fine, they just skinned it, which is a mistake when it’s default.

  • While I think this looks nice, I’m concerned it’s too simple. No tags? Categories? No settings for post slugs?

    Enlighten me here.

  • Maybe this’ll help:

    Admin - Edit Page - Unfolded

Comments are currently closed.