Mailing List Archive

On Mar 4, 2009, at 6:17 PM, Phillip Smith wrote:

> I've seen "Admins" that are also Editors toggle between editing,
> creating categories, etc. So if Admin sub-items moved away from the
> easily accessible sidebar navigation, it would be good to think
> about moving some of those items to the sidebar (or somewhere
> accessible), e.g.: Categories, Keywords, Contributors, etc.
>
> Maybe the real "Admin" stuff -- users, sites, destinations, etc. --
> could be moved away.

Yes. Or optionally allow the creation of contributors and categories
from within a story, as is done for keywords. Then you wouldn't need
the admin interface for editors.

>> Regarding the similar look of desks and edit, I think a different
>> background color between them could help a lot. I think in the
>> long term, a different layout might be better, but I'm not sure at
>> the moment how we'd accomplish that.
>
> Not so sure a colour change will do it.

No, there need to be other queues, since colorblindness is so common.

Best,

David

On Thu, 5 Mar 2009, Phillip Smith wrote:
> Again, I'd love to see us steal some best practices from other CMS UIs
> out there:
> http://nemetral.net/2008/09/03/10-inspiring-admin-interfaces/

What exactly about these UIs is better?

On 5-Mar-09, at 2:28 AM, David E. Wheeler wrote:

> On Mar 4, 2009, at 6:02 PM, Phillip Smith wrote:
>
>> Again, I'd love to see us steal some best practices from other CMS
>> UIs out there:
>> http://nemetral.net/2008/09/03/10-inspiring-admin-interfaces/
>
> If I see one more interface that looks just like Basecamp I'm going
> to scream.


Agreed. I'm not suggestion / proposing any major changes ... just
inviting us to keep an eye on common patterns that are emerging.


>> http://www.flickr.com/photos/factoryjoe/collections/
>
> Can you point to some highlights there? Joe has a bazillion
> screenshots.


Patterns for uploading files / media:
http://www.flickr.com/photos/factoryjoe/sets/72157600039492652/

Adding keywords
http://www.flickr.com/photos/factoryjoe/sets/72157600047722897/

A full set of Drupal 6 screen shots (which demonstrate various UI
approaches to common screens):
http://www.flickr.com/photos/factoryjoe/sets/72157603036774024/

E.g.: How alerts / activity log could be improved:
http://www.flickr.com/photos/factoryjoe/1937397912/in/set-72157603036774024/

E.g.: Javascript form validation and UI feedback:
http://www.flickr.com/photos/factoryjoe/1936557705/in/set-72157603036774024/

E.g.: Collapsed "meta" information on a "Story create" UI:
http://www.flickr.com/photos/factoryjoe/1936558393/in/set-72157603036774024/

Or, looking at WP 2.7:
http://wordpress.org/development/2008/10/the-visual-design-of-27/

There are some good examples of letting the *user* configure the
layout of their Workspace (bigger / longer project, I'm sure), e..g:

* Does the user want the collapsed information for the post inline
(one after another), or in a sidebar?
* Does the user want the panels collapsed or open? (Notice the "Screen
options" tab at the top right)
* Does the user want their "My workspace" page to display any "saved
searches" right there? (See the new WP dashboard)

So, again, I'm not speaking of *specific* layouts or design elements,
but common patterns that are emerging around arranging the UI in a way
that works for each user's personal preference.


>> (... while keep the lovely simplicity of Bricolage's UI)
>
> Um, it's simple? Okay. /me rolls his eyes


Well, using Request Tracker as a comparison, it's simple. ;-)

[snip]


>> And, related to search (and mentioned before on the list), it would
>> be helpful to have some canned / common searches available
>> somewhere, e.g.:
>>
>> * by pre-configured Date range (yesterday, this week, this month)
>> * by Status (published / unpublished / need publishing)
>>
>> Related to that, some "Quicklinks" might also be useful:
>>
>> * Recently created assets
>> * Recently edited assets
>> * Recently published assets
>
> Yep. And a way to save custom searches.


Saved custom searches would be great.


>> * Ability to add a category "on-the-fly" from the Story, or Media
>> edit UI
>
> Huh?
>
>> * Add a contributor "on-the-fly" from the Story, or Media edit UI
>
> Huh? again.


See your own comment re: "Yes. Or optionally allow the creation of
contributors and categories from within a story, as is done for
keywords. Then you wouldn't need the admin interface for editors."

That's what I'm referring to. ;-)



--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On 5-Mar-09, at 7:05 AM, Scott Lanning wrote:

> On Thu, 5 Mar 2009, Phillip Smith wrote:
>> Again, I'd love to see us steal some best practices from other CMS
>> UIs
>> out there:
>> http://nemetral.net/2008/09/03/10-inspiring-admin-interfaces/
>
> What exactly about these UIs is better?

I'm not saying they are *better* ... I'm just pointing out that there
are common patterns for user interaction (for better or worse) that
are developing, and that we can leverage other people's / project's
work on similar UI challenges by keeping an eye on them.


:-)

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Mar 5, 2009, at 6:59 AM, Phillip Smith wrote:

>
> Patterns for uploading files / media:
> http://www.flickr.com/photos/factoryjoe/sets/72157600039492652/

Curious. Those are all pretty mundane.

> Adding keywords
> http://www.flickr.com/photos/factoryjoe/sets/72157600047722897/

I'm pretty happy with the suggest improvements in 2.0.

> A full set of Drupal 6 screen shots (which demonstrate various UI
> approaches to common screens):
> http://www.flickr.com/photos/factoryjoe/sets/72157603036774024/

I like how clean Drupal's admin interface is. Ours, with the hard
colors and borders, is pretty dated.

> E.g.: How alerts / activity log could be improved:
> http://www.flickr.com/photos/factoryjoe/1937397912/in/set-72157603036774024/

Yeah, lots of color would be good.

> E.g.: Javascript form validation and UI feedback:
> http://www.flickr.com/photos/factoryjoe/1936557705/in/set-72157603036774024/

Feedback++

> E.g.: Collapsed "meta" information on a "Story create" UI:
> http://www.flickr.com/photos/factoryjoe/1936558393/in/set-72157603036774024/
>
> Or, looking at WP 2.7:
> http://wordpress.org/development/2008/10/the-visual-design-of-27/

That's closer to what we'd want, I think. I'm not sure about the
reveals in the Drupal interface being *below* the content field. I
know that the content is the most important part, so should be at the
top, but the metadata should then be to the side, perhaps, not below.

> There are some good examples of letting the *user* configure the
> layout of their Workspace (bigger / longer project, I'm sure), e..g:
>
> * Does the user want the collapsed information for the post inline
> (one after another), or in a sidebar?
> * Does the user want the panels collapsed or open? (Notice the
> "Screen options" tab at the top right)
> * Does the user want their "My workspace" page to display any "saved
> searches" right there? (See the new WP dashboard)
>
> So, again, I'm not speaking of *specific* layouts or design
> elements, but common patterns that are emerging around arranging the
> UI in a way that works for each user's personal preference.

Yeah, good.

>>> (... while keep the lovely simplicity of Bricolage's UI)
>>
>> Um, it's simple? Okay. /me rolls his eyes
>
>
> Well, using Request Tracker as a comparison, it's simple. ;-)

Twice nothing is still nothing. ;-P

Best,

David

On Mar 4, 2009, at 9:02 PM, Phillip Smith wrote:

> As long as one tab is "show all." :-)

Is this serious?

> The other option could be collapsed / collapsable divs, e.g., each
> "group" of details can open / closed with a little toggle:
> http://www.flickr.com/photos/factoryjoe/1936558393/sizes/o/in/set-72157603036774024/

We had talked about that idea, but the other way seems cleaner. It
also seems more predictable/a clearer distinction. You're always
going to have content on one tab, meta information on another.

>> * Add a search box in the sidenav workflows
>
> Or... how about just a global search box that's at the top of the
> UI? Why not return anything that matches (all together) vs. just
> stories, or media, or templates?

Because you need to check things out into an associated workflow. I
think implementing that and then defaulting to the first available on
checkout from that search one would be very frustrating for users.

> And, related to search (and mentioned before on the list), it would
> be helpful to have some canned / common searches available
> somewhere, e.g.:

I agree with this - or at least a way to bookmark your searches.

>> * Browsable category interface accessible from sidenav
>
>
> Not sure what this is?

It's described earlier up the thread.

>> * Visually streamline the workspace & desk items
>
> On that point:

> * Help and Log Out could move up to the "Logged in as" area as text
> links.

I like that.

> * Would also like to see the UI open at a larger size, e.g.: 1000px
> wide

Are we at the point where that is feasible? How far back do we want
to support in terms of screen wdith?

> * Buttons for common actions should be at the bottom _and_ top of
> the page -- e.g.: Check In Assets, Select All, and Delete Checked --
> so the user doesn't have to scroll to find them on long pages.

Or be in a section at the top that doesn't scroll so they're always in
the same place.

> * Well, er, while we're on the topic of "buttons," can we get rid of
> them!? ;-) Nicely styled text / css buttons please! (Maybe that's
> already in 1.11/2.0?)

You're free to make your own buttons. We did. But no, I know what
you mean. I will add this as a bug.

> Some other ideas...
>
> * Make it possible to add an asset from any screen, e.g.: At the top
> of the UI have a "Add new [dropdown: Story, Media, Template]"
> widget. If there is more than one workflow for the asset to be a
> part of, maybe that needs to be set on the asset edit screen vs.
> before the asset is created.

I agree that it could be useful, but there's the workflow thing again.

> * Ability to add a category "on-the-fly" from the Story, or Media
> edit UI
> * Add a contributor "on-the-fly" from the Story, or Media edit UI

I think that's in trunk.

> * Change format of WYSIWYG or texarea "on-the-fly," e.g.: Markdown,
> Multimarkdown, Rich Text, Xinha, or JS Quicktags.

Very aspirational.

> Final items on my wishlist:
>
> * Quick / available from My Workspace: Link to full activity log
> * Quick / available from My Workspace: Link to job queue
>
> That's it for tonight. Apologies again for the delay. Hope I'm not
> adding too much work to your pile, Matt! :-)

No problem, I'll just tell you what I can and can't do.

-Matt

BTW, what browsers is 2.0 going to support? I think FF3, Safari 3,
and IE7/8 is the minimum. Anything else?

-Matt

On 5-Mar-09, at 4:33 PM, Matt Rolf wrote:

> On Mar 4, 2009, at 9:02 PM, Phillip Smith wrote:
>
>> As long as one tab is "show all." :-)
>
> Is this serious?


Yes! As a user that *likes* to have all the information available on
one screen, having to switch tabs would drive me nuts. :-)


>> The other option could be collapsed / collapsable divs, e.g., each
>> "group" of details can open / closed with a little toggle:
>> http://www.flickr.com/photos/factoryjoe/1936558393/sizes/o/in/set-72157603036774024/
>
> We had talked about that idea, but the other way seems cleaner. It
> also seems more predictable/a clearer distinction. You're always
> going to have content on one tab, meta information on another.


But some users want / need both available at the same time. ;-)


>>> * Add a search box in the sidenav workflows
>>
>> Or... how about just a global search box that's at the top of the
>> UI? Why not return anything that matches (all together) vs. just
>> stories, or media, or templates?
>
> Because you need to check things out into an associated workflow. I
> think implementing that and then defaulting to the first available
> on checkout from that search one would be very frustrating for users.


Not sure we're on the same page here. But I hear what you're saying.

One search input just seems more straightforward to me than one for
each workflow.



>> And, related to search (and mentioned before on the list), it would
>> be helpful to have some canned / common searches available
>> somewhere, e.g.:
>
> I agree with this - or at least a way to bookmark your searches.
>
>>> * Browsable category interface accessible from sidenav
>>
>>
>> Not sure what this is?
>
> It's described earlier up the thread.


Yep. Found it. :-)


>
>>> * Visually streamline the workspace & desk items
>>
>> On that point:
>
>> * Help and Log Out could move up to the "Logged in as" area as text
>> links.
>
> I like that.
>
>> * Would also like to see the UI open at a larger size, e.g.: 1000px
>> wide
>
> Are we at the point where that is feasible? How far back do we want
> to support in terms of screen wdith?


*Every* news site has moved to the 1024px wide assumption (NYT, BBC,
CNN, etc., etc., etc.): so I would say that Web community has
determined that's the target.

That said, one could always make their window *smaller* should they
want to.

Let's target the 80% not the 20%. :-)


>> * Buttons for common actions should be at the bottom _and_ top of
>> the page -- e.g.: Check In Assets, Select All, and Delete Checked
>> -- so the user doesn't have to scroll to find them on long pages.
>
> Or be in a section at the top that doesn't scroll so they're always
> in the same place.


Yep. Like that too.


>> * Well, er, while we're on the topic of "buttons," can we get rid
>> of them!? ;-) Nicely styled text / css buttons please! (Maybe
>> that's already in 1.11/2.0?)
>
> You're free to make your own buttons. We did. But no, I know what
> you mean. I will add this as a bug.

:-)


>> Some other ideas...
>>
>> * Make it possible to add an asset from any screen, e.g.: At the
>> top of the UI have a "Add new [dropdown: Story, Media, Template]"
>> widget. If there is more than one workflow for the asset to be a
>> part of, maybe that needs to be set on the asset edit screen vs.
>> before the asset is created.
>
> I agree that it could be useful, but there's the workflow thing again.


Let's use some AJAX here:

* Add new
* User selects story
* AJAX widget / modal window asks for workflow (if there's more than
one!)
* User flow continues as it usually would


>> * Ability to add a category "on-the-fly" from the Story, or Media
>> edit UI
>> * Add a contributor "on-the-fly" from the Story, or Media edit UI
>
> I think that's in trunk.


Awesome.


>> * Change format of WYSIWYG or texarea "on-the-fly," e.g.: Markdown,
>> Multimarkdown, Rich Text, Xinha, or JS Quicktags.
>
> Very aspirational.


That's me. :-)


>> Final items on my wishlist:
>>
>> * Quick / available from My Workspace: Link to full activity log
>> * Quick / available from My Workspace: Link to job queue
>>
>> That's it for tonight. Apologies again for the delay. Hope I'm not
>> adding too much work to your pile, Matt! :-)
>
> No problem, I'll just tell you what I can and can't do.


You are "the man." :-)

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Mar 5, 2009, at 11:11 AM, Matt Rolf wrote:

> BTW, what browsers is 2.0 going to support? I think FF3, Safari 3,
> and IE7/8 is the minimum. Anything else?

I think we need to be more conservative than that, I'm afraid. Target
your changes or those versions, but we'll likely need to make more
fixes for IE 6 and FF2. Remember the types of users that WHO has, for
example.

Best,

David

On Mar 5, 2009, at 7:12 PM, David E. Wheeler wrote:

> On Mar 5, 2009, at 11:11 AM, Matt Rolf wrote:
>
>> BTW, what browsers is 2.0 going to support? I think FF3, Safari 3,
>> and IE7/8 is the minimum. Anything else?
>
> I think we need to be more conservative than that, I'm afraid.
> Target your changes or those versions, but we'll likely need to make
> more fixes for IE 6 and FF2. Remember the types of users that WHO
> has, for example.

That's fine. I just wanted to know where we were at.

-Matt

On Mar 5, 2009, at 2:20 PM, Phillip Smith wrote:

> Yes! As a user that *likes* to have all the information available on
> one screen, having to switch tabs would drive me nuts. :-)

Right now the UI is optimized(ish) for the power user. I think I'd
like to see that tilt toward the people who just want to edit some
content. Certainly there are tradeoffs in various approaches. You've
used Drupal as an example in more than one place - yet a user can
hardly do anything on some of those screens. 1-2 tasks, tops.

I'll keep what you've said in mind. I'll be playing with some things,
so we'll see how it turns out.

>> Because you need to check things out into an associated workflow.
>> I think implementing that and then defaulting to the first
>> available on checkout from that search one would be very
>> frustrating for users.
>
> Not sure we're on the same page here. But I hear what you're saying.
>
> One search input just seems more straightforward to me than one for
> each workflow.

It does seem more straight forward, but


> *Every* news site has moved to the 1024px wide assumption (NYT, BBC,
> CNN, etc., etc., etc.): so I would say that Web community has
> determined that's the target.

Well, looking at the css, we're already at 800. So it's not too much
of a jump.

-Matt

Regarding the visual look of Bricolage, I'm going to significantly
tone down the visual contrast. We did that somewhat with our current
install, but I think it should be done even more for 2.0. I think a
reduced color palette and more subtle highlighting of some elements
will produce a more calming look.

At the same time, I'm leery of making Bricolage look like Drupal, or
Basecamp, or every other app/website out there.

http://www.griptechnology.com/

Looks a bit silly and slavish, doesn't it?

Bricolage should convey that it is it's own application, with it's own
way of doing things. It shouldn't beat the user over the head to make
them get things done, but it is a "power" application. The visual
design should convey that sense of raw power.

And no, I'm not going to replace the Bricolage logo with a Ford
Mustang or something. That'd be over the top.

Anyway, just some thoughts about where I'm headed.

-Matt

Oh, one more thing - would anyone be sad if I just killed the bread
crumbs? We've found them to be pretty useless - the top title of the
page usually does a decent job of showing where you are on the site.

-Matt

I sure wouldn't mind. They've been helpful in earlier versions, but now
that all the subelements are inline, I won't be sad to see them go.

On the overall approach, I thought I'd chime in a few thoughts (late
being better than never, presumably).

1. Bricolage is a powerful application. Super duper powerful. If this is
a problem for some classes of users, that problem should be addressed.
(Which means hiding some of the power from some users.)

2. But.

3. The thing about having a powerful application is that some users get
very skilled, and they want all that power at their fingertips. It's
frustrating to have to do all kinds of clicking to get at hidden
functions.

4. So I'd like to argue for keeping a "see all" tab, or some way of
keeping the full-strength functionality of Bricolage available. Or at
least some way of offering the full-strength version to certain classes
of user.

5. There has to be a way to let icons be icons and labels be labels,
without needing to burn text into image files. (I'd be happy to help
with the fiddly CSS to make this happen.)

6. Er,

7. That's it!


Thanks for taking this on, Matt.

Cheers,

Bret



On Sat, 2009-03-07 at 09:02 -0500, Matt Rolf wrote:
> Oh, one more thing - would anyone be sad if I just killed the bread
> crumbs? We've found them to be pretty useless - the top title of the
> page usually does a decent job of showing where you are on the site.
>
> -Matt
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

On Mar 7, 2009, at 9:23 AM, Bret Dawson wrote:

> 4. So I'd like to argue for keeping a "see all" tab, or some way of
> keeping the full-strength functionality of Bricolage available. Or at
> least some way of offering the full-strength version to certain
> classes
> of user.

Understandable.

> 5. There has to be a way to let icons be icons and labels be labels,
> without needing to burn text into image files. (I'd be happy to help
> with the fiddly CSS to make this happen.)

Yes, I think there is. Let me work on it a bit and get back to you.

I've been thinking about workflows since my last messages. I think
Philip's right in that it would make sense to have global workflow
navigation. After looking at other apps, it strikes me that unless
you've got things checked out, Bricolage doesn't give you much clue as
to where you got to go to do stuff. Also, after logging in, it takes
a minimum of one click to get your functional links, and at least two
more to find something. Elevating Find/New/ Search to the persistent
zone would greatly reduce the learning curve/user frustration level, I
think.

The problem with that comes with there being this sort of contextual
editing tree:

Site
Workflow
New/Find/Edit/Active/Desks

Users are *always* dropped into a Site context, and can move to others
if they have access. However, we make them *chose* a workflow with
the side navigation. We could make workflow selection similar to site
context selection - that is, via dropdown w/ the first avaiable being
the default. I'm a little worried about whether that would be too
confusing or not. If we did do that, it *would* open up a whole new
way to rework the navigation.

Of course, we could just make the workflows more visually engaging -
right now they are the same color background as the preview links in
the workspace. By toning down the rest of the app, we could up the
workflow contrast to something that says "click me" louder than it
does now.

-Matt

On Mar 7, 2009, at 5:44 AM, Matt Rolf wrote:

> Regarding the visual look of Bricolage, I'm going to significantly
> tone down the visual contrast. We did that somewhat with our
> current install, but I think it should be done even more for 2.0. I
> think a reduced color palette and more subtle highlighting of some
> elements will produce a more calming look.
>
> At the same time, I'm leery of making Bricolage look like Drupal, or
> Basecamp, or every other app/website out there.

+1

> http://www.griptechnology.com/
>
> Looks a bit silly and slavish, doesn't it?

Hello Apple!

> Bricolage should convey that it is it's own application, with it's
> own way of doing things. It shouldn't beat the user over the head
> to make them get things done, but it is a "power" application. The
> visual design should convey that sense of raw power.
>
> And no, I'm not going to replace the Bricolage logo with a Ford
> Mustang or something. That'd be over the top.
>
> Anyway, just some thoughts about where I'm headed.

Sounds good, thanks Matt.

David

On Mar 7, 2009, at 6:02 AM, Matt Rolf wrote:

> Oh, one more thing - would anyone be sad if I just killed the bread
> crumbs? We've found them to be pretty useless - the top title of
> the page usually does a decent job of showing where you are on the
> site.

I like it when we delete stuff. :-)

David

On Mar 7, 2009, at 6:23 AM, Bret Dawson wrote:

> 4. So I'd like to argue for keeping a "see all" tab, or some way of
> keeping the full-strength functionality of Bricolage available. Or at
> least some way of offering the full-strength version to certain
> classes
> of user.

+1. Make it friendly to casual users, but accessible for power users.

> 5. There has to be a way to let icons be icons and labels be labels,
> without needing to burn text into image files. (I'd be happy to help
> with the fiddly CSS to make this happen.)

God yes, please. I hate the image buttons.

David

On Mar 7, 2009, at 7:40 AM, Matt Rolf wrote:

> Users are *always* dropped into a Site context, and can move to
> others if they have access. However, we make them *chose* a
> workflow with the side navigation. We could make workflow selection
> similar to site context selection - that is, via dropdown w/ the
> first avaiable being the default. I'm a little worried about
> whether that would be too confusing or not. If we did do that, it
> *would* open up a whole new way to rework the navigation.

Sounds good. The site context should probably be moved into the user
object, rather than the session or server cache, whichever it is now.
It's a bit too unpredictable. The associated workflow contexts should
also be serialized.

> Of course, we could just make the workflows more visually engaging -
> right now they are the same color background as the preview links in
> the workspace. By toning down the rest of the app, we could up the
> workflow contrast to something that says "click me" louder than it
> does now.

Yah.

David

On 7-Mar-09, at 8:19 PM, David E. Wheeler wrote:

> On Mar 7, 2009, at 7:40 AM, Matt Rolf wrote:
>
>> Users are *always* dropped into a Site context, and can move to
>> others if they have access. However, we make them *chose* a
>> workflow with the side navigation. We could make workflow
>> selection similar to site context selection - that is, via dropdown
>> w/ the first avaiable being the default. I'm a little worried
>> about whether that would be too confusing or not. If we did do
>> that, it *would* open up a whole new way to rework the navigation.
>
> Sounds good. The site context should probably be moved into the user
> object, rather than the session or server cache, whichever it is
> now. It's a bit too unpredictable. The associated workflow contexts
> should also be serialized.
>
>> Of course, we could just make the workflows more visually engaging
>> - right now they are the same color background as the preview links
>> in the workspace. By toning down the rest of the app, we could up
>> the workflow contrast to something that says "click me" louder than
>> it does now.
>
> Yah.


+1 on both.


--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Mar 9, 2009, at 9:31 AM, Phillip Smith wrote:

> +1 on both.

Ok. I think what I'm going to work on in the near term is #2 so as to
get 2.0 out the door. But I think #1 is where we ultimately want to be.

-matt