Mailing List Archive: Bricolage: devel

Bricolage UI Changes

1 2 3

View All

Index | Next | Previous | View Threaded

rolfm at denison

Dec 17, 2008, 6:29 AM

Post #1 of 71 (7671 views)
Permalink

Bricolage UI Changes

Over here at Denison we've talked about making changes to the
Bricolage UI. Most of these changes revolve around streamlining the
story profile or admin sections.

Let's start with the story profile. The *vast* majority of our users
just care about the content section. They do not change output
channels, they don't add or subtract contributors, and they rarely
change category. Ideally, we feel that the initial view of the story
profile should be stripped down to just the content section, the
preview link, and the controlling links. It would be similar to the
old element profile screen, but even more stripped down.

How could that be accomplished? One idea that we have had is
eliminating the breadcrumbs at the top of the page since they are not
very useful in practice, and replacing them with app-style dropdown
menus. Clicking on one could show a hidden div with the interface
window for . So we'd have

Information
Categories
Output Channels
Contributors
Keywords

And you could even break down the information one more into one or two
more tabs.

Regarding the Admin section, every single initial page is a search box
with a results list below it - quite simple, really. We've toyed with
the idea of moving the menu up to the top of the screen - placing
Admin, Publishing, and Distribution directly below the MyWorkSpace
link, and then placing the submenus along the top of the screen as
opposed to being a drop down. At some level it's just moving things
around, but it would make it more natural to the user by being at the
top, and its location less subject to how many workflows are in a
typical install. After that, I think there's work that could be done
to style those aspects of the interface and make them more sexy.

Obviously these changes aren't going to make it into 2.0 even if we
develop them to the point of good ideas, but what we would like to
explore for 2.0 is putting the majority of the "Information" section
into a div that gets shown or hidden much like the advanced search
feature now does in 2.0. It looks like it would be relatively simple
to do, and would keep Bricolage trainers from having to tell users to
"scroll down" every time they want to do something.

I'm interested to hear what others think - I know that Mr. Lanning in
particular has recently voiced frustration with the ui. So let's
start a discussion about where we want to take the ui in the future.

As an aside, the Bricolage CSS is a nightmare - you know the Seinfeld
episode where Jackie is trying to sue the cigarette companies and
describes Kramer as a goblin? Yeah, that. The main css file is 27kb
and overloaded with selectors that are overly specific and far too
many !importants. We found out just how difficult it was to work with
when we redid the desk-item buttons. I recently reorganized the
Denison CSS (which was a lurching monstrosity in its own right) along
the lines of this blog entry -

http://meiert.com/en/blog/20080515/css-organization-and-efficiency/

Following a lot of the guidelines, we cut our CSS size by about 60%
and made it much more readable. If nobody has objection, I'll take a
stab at the bricolage css in the same manner in the near future. That
would would make future UI changes easier to implement.

-Matt

D-Beaudet at NGA

Dec 17, 2008, 6:58 AM

Post #2 of 71 (7529 views)
Permalink

RE: Bricolage UI Changes [In reply to]

I'd welcome these as a start. I'd also like to see more information
about story status in search results... the content of the information
could easily be richer than this

http://www.flickr.com/photos/beaudet/465261462/sizes/l/

but laid out in a way that makes better use of real-estate... or for
some of it, with pop-ups for information that's not important for page
scanning purposes... such as the live links... actually, that would make
a great pop-up... put the live link inside a pop-up div when someone
clicks on it.

Anyway, another majorly useful GUI enhancement IMHO would be the ability
to edit content by clicking on pop-up links that appear when mousing
over the preview site. The actions available in the GUI could be
carried through to that interface. Users would then have the option of
editing in a more contextual interface.

> -----Original Message-----
> From: Matt Rolf [mailto:rolfm [at] denison]
> Sent: Wednesday, December 17, 2008 9:30 AM
> To: devel [at] lists
> Cc: Aaron Fuleki
> Subject: Bricolage UI Changes
>
> Over here at Denison we've talked about making changes to the
> Bricolage UI. Most of these changes revolve around streamlining the
> story profile or admin sections.
>
> Let's start with the story profile. The *vast* majority of our users
> just care about the content section. They do not change output
> channels, they don't add or subtract contributors, and they rarely
> change category. Ideally, we feel that the initial view of the story
> profile should be stripped down to just the content section, the
> preview link, and the controlling links. It would be similar to the
> old element profile screen, but even more stripped down.
>
> How could that be accomplished? One idea that we have had is
> eliminating the breadcrumbs at the top of the page since they are not
> very useful in practice, and replacing them with app-style dropdown
> menus. Clicking on one could show a hidden div with the interface
> window for . So we'd have
>
> Information
> Categories
> Output Channels
> Contributors
> Keywords
>
> And you could even break down the information one more into one or two
> more tabs.
>
> Regarding the Admin section, every single initial page is a search box
> with a results list below it - quite simple, really. We've toyed with
> the idea of moving the menu up to the top of the screen - placing
> Admin, Publishing, and Distribution directly below the MyWorkSpace
> link, and then placing the submenus along the top of the screen as
> opposed to being a drop down. At some level it's just moving things
> around, but it would make it more natural to the user by being at the
> top, and its location less subject to how many workflows are in a
> typical install. After that, I think there's work that could be done
> to style those aspects of the interface and make them more sexy.
>
> Obviously these changes aren't going to make it into 2.0 even if we
> develop them to the point of good ideas, but what we would like to
> explore for 2.0 is putting the majority of the "Information" section
> into a div that gets shown or hidden much like the advanced search
> feature now does in 2.0. It looks like it would be relatively simple
> to do, and would keep Bricolage trainers from having to tell users to
> "scroll down" every time they want to do something.
>
> I'm interested to hear what others think - I know that Mr. Lanning in
> particular has recently voiced frustration with the ui. So let's
> start a discussion about where we want to take the ui in the future.
>
> As an aside, the Bricolage CSS is a nightmare - you know the Seinfeld
> episode where Jackie is trying to sue the cigarette companies and
> describes Kramer as a goblin? Yeah, that. The main css file is 27kb
> and overloaded with selectors that are overly specific and far too
> many !importants. We found out just how difficult it was to work with
> when we redid the desk-item buttons. I recently reorganized the
> Denison CSS (which was a lurching monstrosity in its own right) along
> the lines of this blog entry -
>
> http://meiert.com/en/blog/20080515/css-organization-and-efficiency/
>
> Following a lot of the guidelines, we cut our CSS size by about 60%
> and made it much more readable. If nobody has objection, I'll take a
> stab at the bricolage css in the same manner in the near future. That
> would would make future UI changes easier to implement.
>
> -Matt

phillip at communitybandwidth

Dec 17, 2008, 7:15 AM

Post #3 of 71 (7524 views)
Permalink

Re: Bricolage UI Changes [In reply to]

Hi ho,

Jumping in with a few cents:

+1 on the idea of reorganizing / cleaning up the CSS.

I think David W has mentioned "themes" before, which would change the
layout / appearance of the Admin UI. A "theme" approach could have the
benefit of making it possible to address different administrative
layout needs. Otherwise, we're back to a "one size fits all" approach.

Piggybacking on David B's comment below: I would add that it may be
worth some time to discuss the different aspects of the Admin UI that
need to be improved, i.e., there's the layout of existing information,
and then there's the question of adding new information to the UI.

Finally, my guess is that many people on this list have opinions about
which direction to explore when re-thinking the UI. And, it is likely
that those opinions will differ greatly. So my preemptive proposal,
before the conversation gets too far along, is that the process start
by looking at the existing design patterns out there for similar
systems. Perhaps we can agree on some general information design / UI
layout approaches before getting into specifics?

I submit these recent blog / CMS product launches that sport improved
user interfaces as a conversation starter:

http://wordpress.org/development/2008/12/coltrane/
http://www.movabletype.com/overview/
http://media.ellingtoncms.com/ellingtoncms/img/graphics/ellington_admin_full.jpg

Any Chris Messina's collection of design patterns may also be a useful
resource:
http://www.flickr.com/photos/factoryjoe/collections/72157600001823120/

Maybe that more than a "few cents," but it's the cents I got today! ;-)

Best,

Phillip.

On 17-Dec-08, at 9:58 AM, Beaudet, David wrote:

>
> I'd welcome these as a start. I'd also like to see more information
> about story status in search results... the content of the information
> could easily be richer than this
>
> http://www.flickr.com/photos/beaudet/465261462/sizes/l/
>
> but laid out in a way that makes better use of real-estate... or for
> some of it, with pop-ups for information that's not important for page
> scanning purposes... such as the live links... actually, that would
> make
> a great pop-up... put the live link inside a pop-up div when someone
> clicks on it.
>
> Anyway, another majorly useful GUI enhancement IMHO would be the
> ability
> to edit content by clicking on pop-up links that appear when mousing
> over the preview site. The actions available in the GUI could be
> carried through to that interface. Users would then have the option
> of
> editing in a more contextual interface.
>
>
>> -----Original Message-----
>> From: Matt Rolf [mailto:rolfm [at] denison]
>> Sent: Wednesday, December 17, 2008 9:30 AM
>> To: devel [at] lists
>> Cc: Aaron Fuleki
>> Subject: Bricolage UI Changes
>>
>> Over here at Denison we've talked about making changes to the
>> Bricolage UI. Most of these changes revolve around streamlining the
>> story profile or admin sections.
>>
>> Let's start with the story profile. The *vast* majority of our users
>> just care about the content section. They do not change output
>> channels, they don't add or subtract contributors, and they rarely
>> change category. Ideally, we feel that the initial view of the story
>> profile should be stripped down to just the content section, the
>> preview link, and the controlling links. It would be similar to the
>> old element profile screen, but even more stripped down.
>>
>> How could that be accomplished? One idea that we have had is
>> eliminating the breadcrumbs at the top of the page since they are not
>> very useful in practice, and replacing them with app-style dropdown
>> menus. Clicking on one could show a hidden div with the interface
>> window for . So we'd have
>>
>> Information
>> Categories
>> Output Channels
>> Contributors
>> Keywords
>>
>> And you could even break down the information one more into one or
>> two
>> more tabs.
>>
>> Regarding the Admin section, every single initial page is a search
>> box
>> with a results list below it - quite simple, really. We've toyed
>> with
>> the idea of moving the menu up to the top of the screen - placing
>> Admin, Publishing, and Distribution directly below the MyWorkSpace
>> link, and then placing the submenus along the top of the screen as
>> opposed to being a drop down. At some level it's just moving things
>> around, but it would make it more natural to the user by being at the
>> top, and its location less subject to how many workflows are in a
>> typical install. After that, I think there's work that could be done
>> to style those aspects of the interface and make them more sexy.
>>
>> Obviously these changes aren't going to make it into 2.0 even if we
>> develop them to the point of good ideas, but what we would like to
>> explore for 2.0 is putting the majority of the "Information" section
>> into a div that gets shown or hidden much like the advanced search
>> feature now does in 2.0. It looks like it would be relatively simple
>> to do, and would keep Bricolage trainers from having to tell users to
>> "scroll down" every time they want to do something.
>>
>> I'm interested to hear what others think - I know that Mr. Lanning in
>> particular has recently voiced frustration with the ui. So let's
>> start a discussion about where we want to take the ui in the future.
>>
>> As an aside, the Bricolage CSS is a nightmare - you know the Seinfeld
>> episode where Jackie is trying to sue the cigarette companies and
>> describes Kramer as a goblin? Yeah, that. The main css file is 27kb
>> and overloaded with selectors that are overly specific and far too
>> many !importants. We found out just how difficult it was to work
>> with
>> when we redid the desk-item buttons. I recently reorganized the
>> Denison CSS (which was a lurching monstrosity in its own right) along
>> the lines of this blog entry -
>>
>> http://meiert.com/en/blog/20080515/css-organization-and-efficiency/
>>
>> Following a lot of the guidelines, we cut our CSS size by about 60%
>> and made it much more readable. If nobody has objection, I'll take a
>> stab at the bricolage css in the same manner in the near future.
>> That
>> would would make future UI changes easier to implement.
>>
>> -Matt

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

lannings at who

Dec 17, 2008, 7:23 AM

Post #4 of 71 (7547 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Wed, 17 Dec 2008, Matt Rolf wrote:
> Let's start with the story profile. The *vast* majority of our users
> just care about the content section. [...]
> Ideally, we feel that the initial view of the story profile should be
> stripped down to just the content section, the preview link, and the
> controlling links. [...]
>
> One idea that we have had is eliminating the breadcrumbs at the top
> of the page [...] and replacing them with app-style dropdown menus.

Not sure what you mean by app-style dropdown menus.

There should probably be preferences for showing various things,
so they can be set per-user and globally.
We had a discussion like this a few years ago on the desk display.

I thought there was some work done on expandable/collapseable
element boxes. Those could be used for the meta-info section
(except the preview link) and the bottom section, and prefs
that decide whether they're initially expanded or shown at all.

> Obviously these changes aren't going to make it into 2.0 even if
> we develop them to the point of good ideas,

It's not obvious to me.

> but what we would like to explore for 2.0 is
> putting the majority of the "Information" section into a div that gets shown
> or hidden much like the advanced search feature now does in 2.0.

Yeah. The "INFORMATION" box could be rearranged, in any case,
to be more compact. Or you could have a tooltip dialog
(like on flickr, those dialogs that popup when you click
on images; but they'd have most of the metadata info;
maybe when you click on a "meta" icon beside the "trail"
and "notes" (if those are still there in 2.0), or when you
hover over something like the URL).

> I'm interested to hear what others think - I know that Mr. Lanning
> in particular has recently voiced frustration with the ui.
> So let's start a discussion about where we want to take the ui
> in the future.

Out back and shot? Mais, non.

I personally won't be satisfied until Bricolage turns
into a 3D-game interface. I still think the idea of
harpooning whales as a metaphor for related links could work.

(Mais, non. Monsieur Lanning?)

lannings at who

Dec 17, 2008, 7:26 AM

Post #5 of 71 (7515 views)
Permalink

RE: Bricolage UI Changes [In reply to]

On Wed, 17 Dec 2008, Beaudet, David wrote:
> Anyway, another majorly useful GUI enhancement IMHO would be the ability
> to edit content by clicking on pop-up links that appear when mousing
> over the preview site. The actions available in the GUI could be
> carried through to that interface. Users would then have the option of
> editing in a more contextual interface.

AFAIK, GT are working on something like this for us,
for early next year.

rolfm at denison

Dec 17, 2008, 7:28 AM

Post #6 of 71 (7541 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 10:26 AM, Scott Lanning wrote:

> On Wed, 17 Dec 2008, Beaudet, David wrote:
>> Anyway, another majorly useful GUI enhancement IMHO would be the
>> ability
>> to edit content by clicking on pop-up links that appear when mousing
>> over the preview site. The actions available in the GUI could be
>> carried through to that interface. Users would then have the
>> option of
>> editing in a more contextual interface.
>
> AFAIK, GT are working on something like this for us,
> for early next year.

Any plans to contribute it back?

lannings at who

Dec 17, 2008, 7:30 AM

Post #7 of 71 (7529 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Wed, 17 Dec 2008, Phillip Smith wrote:
> I think David W has mentioned "themes" before, which would change the layout
> / appearance of the Admin UI. A "theme" approach could have the benefit of
> making it possible to address different administrative layout needs.
> Otherwise, we're back to a "one size fits all" approach.

I think we basically want a customizeable "portal".
A REST interface and components that use it that you pick and choose from.
Good luck. :D

lannings at who

Dec 17, 2008, 7:31 AM

Post #8 of 71 (7525 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Wed, 17 Dec 2008, Matt Rolf wrote:
> On Dec 17, 2008, at 10:26 AM, Scott Lanning wrote:
>> On Wed, 17 Dec 2008, Beaudet, David wrote:
>>> Anyway, another majorly useful GUI enhancement IMHO would be the ability
>>> to edit content by clicking on pop-up links that appear when mousing
>>> over the preview site. The actions available in the GUI could be
>>> carried through to that interface. Users would then have the option of
>>> editing in a more contextual interface.
>>
>> AFAIK, GT are working on something like this for us,
>> for early next year.
>
> Any plans to contribute it back?

Sure. It'd be cruel to mention it, otherwise. :>

rolfm at denison

Dec 17, 2008, 7:36 AM

Post #9 of 71 (7532 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 10:31 AM, Scott Lanning wrote:

>>> Any plans to contribute it back?
>
> Sure. It'd be cruel to mention it, otherwise. :>

Well, yes - is that all together out of character, though? ;)

phillip at communitybandwidth

Dec 17, 2008, 7:37 AM

Post #10 of 71 (7544 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On 17-Dec-08, at 10:30 AM, Scott Lanning wrote:

> On Wed, 17 Dec 2008, Phillip Smith wrote:
>> I think David W has mentioned "themes" before, which would change
>> the layout / appearance of the Admin UI. A "theme" approach could
>> have the benefit of making it possible to address different
>> administrative layout needs. Otherwise, we're back to a "one size
>> fits all" approach.
>
> I think we basically want a customizeable "portal".
> A REST interface and components that use it that you pick and choose
> from.

Have a look at the video walkthrough of the new Wordpress UI:
http://wordpress.org/development/2008/12/coltrane/

Sure, it's Wordpress -- but we can learn from their UI designers.

Phillip.

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

rolfm at denison

Dec 17, 2008, 8:03 AM

Post #11 of 71 (7542 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:

> \Finally, my guess is that many people on this list have opinions
> about which direction to explore when re-thinking the UI. And, it is
> likely that those opinions will differ greatly. So my preemptive
> proposal, before the conversation gets too far along, is that the
> process start by looking at the existing design patterns out there
> for similar systems. Perhaps we can agree on some general
> information design / UI layout approaches before getting into
> specifics?

DSpace has a very nice administrative interface - much more integrated
and automated than our current ui.

rolfm at denison

Dec 17, 2008, 8:06 AM

Post #12 of 71 (7528 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 10:23 AM, Scott Lanning wrote:

> On Wed, 17 Dec 2008, Matt Rolf wrote:
>> Let's start with the story profile. The *vast* majority of our users
>> just care about the content section. [...]
>> Ideally, we feel that the initial view of the story profile should be
>> stripped down to just the content section, the preview link, and the
>> controlling links. [...]
>>
>> One idea that we have had is eliminating the breadcrumbs at the top
>> of the page [...] and replacing them with app-style dropdown menus.
>
> Not sure what you mean by app-style dropdown menus.

Similar to those on the toolbar of a mac.

>> Obviously these changes aren't going to make it into 2.0 even if
>> we develop them to the point of good ideas,
>
> It's not obvious to me.

Well, there was talk of a feature freeze taking place in two days.
I'm not sure how I feel about rolling in major ui changes in addition
to what we've got in that version - my immediate reaction is to push
it to the next release.

>> but what we would like to explore for 2.0 is
>> putting the majority of the "Information" section into a div that
>> gets shown
>> or hidden much like the advanced search feature now does in 2.0.
>
> Yeah. The "INFORMATION" box could be rearranged, in any case,
> to be more compact. Or you could have a tooltip dialog
> (like on flickr, those dialogs that popup when you click
> on images; but they'd have most of the metadata info;
> maybe when you click on a "meta" icon beside the "trail"
> and "notes" (if those are still there in 2.0), or when you
> hover over something like the URL).

Yes, I believe that's our thought. Our suggestion was based on ease
of implementation and the fact that there's at least some sort of
current ui precedent.

>> I'm interested to hear what others think - I know that Mr. Lanning
>> in particular has recently voiced frustration with the ui.
>> So let's start a discussion about where we want to take the ui
>> in the future.
>
> Out back and shot? Mais, non.

That is a good idea.

> I personally won't be satisfied until Bricolage turns
> into a 3D-game interface. I still think the idea of
> harpooning whales as a metaphor for related links could work.

W1nn4r. Post of the day. Is Wolfenstein public domain yet?

phillip at communitybandwidth

Dec 17, 2008, 8:12 AM

Post #13 of 71 (7531 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:

>
> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
>
>> \Finally, my guess is that many people on this list have opinions
>> about which direction to explore when re-thinking the UI. And, it
>> is likely that those opinions will differ greatly. So my
>> preemptive proposal, before the conversation gets too far along, is
>> that the process start by looking at the existing design patterns
>> out there for similar systems. Perhaps we can agree on some general
>> information design / UI layout approaches before getting into
>> specifics?
>
> DSpace has a very nice administrative interface - much more
> integrated and automated than our current ui.

Screenshot?

Perhaps we could collect screenshots of UI patterns that we could
review and comment on a a group?

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

john.durkin at gmail

Dec 17, 2008, 1:35 PM

Post #14 of 71 (7537 views)
Permalink

Re: Bricolage UI Changes [In reply to]

Hooray for this discussion. My bricolage install is gradually morphing into
a strange hybrid of a custom mysql/php cms crossed with bric. I just
completed my first bricolage deployment to an entirely CMS-naive
blogforce... and while they're good sports, it's tough selling them on the
UI... a lot of apologizing for the quirkiness, etc.
My biggest problem right now is the WYSIWYG contents disappearing when you
hit "add element" unless you've just hit save and stay... (1.11.1+)

My second biggest problem is the arrangement of the save, save and stay,
check in buttons. I need my users to "check in AND publish" most of the
time. unfortunately, the big red save button tempts them, and they click it
instead. if they're doing this on a media item they just created and are in
the process of relating to a story, they hit save, the window closes, their
image is related, but then they go to publish their story and they get an
error because a related media item is sitting saved on their desk instead of
having been published.

The arrangement of those three buttons and the end of media / story profile
pages drives me nuts.

jquery is my favorite for ajax - don't think it was out when marshall did
that work. check out this - jeditable -

http://www.appelsiini.net/projects/jeditable

must get back to production work - but the UI - IMHO - is the most critical
thing we must address to keep bric going...

On Wed, Dec 17, 2008 at 8:12 AM, Phillip Smith <
phillip [at] communitybandwidth> wrote:

>
> On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:
>
>
>> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
>>
>> \Finally, my guess is that many people on this list have opinions about
>>> which direction to explore when re-thinking the UI. And, it is likely that
>>> those opinions will differ greatly. So my preemptive proposal, before the
>>> conversation gets too far along, is that the process start by looking at the
>>> existing design patterns out there for similar systems. Perhaps we can agree
>>> on some general information design / UI layout approaches before getting
>>> into specifics?
>>>
>>
>> DSpace has a very nice administrative interface - much more integrated and
>> automated than our current ui.
>>
>
>
> Screenshot?
>
>
> Perhaps we could collect screenshots of UI patterns that we could review
> and comment on a a group?
>
>
>
> --
> Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
> www.communitybandwidth.ca // www.communitybandwidth.ca/phillipadsmith
>
>
>
>
>

D-Beaudet at NGA

Dec 17, 2008, 1:42 PM

Post #15 of 71 (7525 views)
Permalink

RE: Bricolage UI Changes [In reply to]

I agree that JQuery is probably a better option (in retrospect) than
Scriptaculous, but who this space has developed so much in the last two
years, there was no way to know... at least it's ajaxified for now.
Might make a good project to convert to JQuery.

> -----Original Message-----
> From: John Durkin [mailto:john.durkin [at] gmail]
> Sent: Wednesday, December 17, 2008 4:36 PM
> To: devel [at] lists
> Subject: Re: Bricolage UI Changes
>
> Hooray for this discussion. My bricolage install is gradually
morphing
> into
> a strange hybrid of a custom mysql/php cms crossed with bric. I just
> completed my first bricolage deployment to an entirely CMS-naive
> blogforce... and while they're good sports, it's tough selling them on
the
> UI... a lot of apologizing for the quirkiness, etc.
> My biggest problem right now is the WYSIWYG contents disappearing when
you
> hit "add element" unless you've just hit save and stay... (1.11.1+)
>
> My second biggest problem is the arrangement of the save, save and
stay,
> check in buttons. I need my users to "check in AND publish" most of
the
> time. unfortunately, the big red save button tempts them, and they
click
> it
> instead. if they're doing this on a media item they just created and
are
> in
> the process of relating to a story, they hit save, the window closes,
> their
> image is related, but then they go to publish their story and they get
an
> error because a related media item is sitting saved on their desk
instead
> of
> having been published.
>
> The arrangement of those three buttons and the end of media / story
> profile
> pages drives me nuts.
>
> jquery is my favorite for ajax - don't think it was out when marshall
did
> that work. check out this - jeditable -
>
> http://www.appelsiini.net/projects/jeditable
>
> must get back to production work - but the UI - IMHO - is the most
> critical
> thing we must address to keep bric going...
>
> On Wed, Dec 17, 2008 at 8:12 AM, Phillip Smith <
> phillip [at] communitybandwidth> wrote:
>
> >
> > On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:
> >
> >
> >> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
> >>
> >> \Finally, my guess is that many people on this list have opinions
> about
> >>> which direction to explore when re-thinking the UI. And, it is
likely
> that
> >>> those opinions will differ greatly. So my preemptive proposal,
before
> the
> >>> conversation gets too far along, is that the process start by
looking
> at the
> >>> existing design patterns out there for similar systems. Perhaps we
can
> agree
> >>> on some general information design / UI layout approaches before
> getting
> >>> into specifics?
> >>>
> >>
> >> DSpace has a very nice administrative interface - much more
integrated
> and
> >> automated than our current ui.
> >>
> >
> >
> > Screenshot?
> >
> >
> > Perhaps we could collect screenshots of UI patterns that we could
review
> > and comment on a a group?
> >
> >
> >
> > --
> > Phillip Smith // Simplifier of Technology // COMMUNITY
BANDWIDTH
> > www.communitybandwidth.ca //
> www.communitybandwidth.ca/phillipadsmith
> >
> >
> >
> >
> >

marshall at exclupen

Dec 17, 2008, 6:55 PM

Post #16 of 71 (7531 views)
Permalink

Re: Bricolage UI Changes [In reply to]

I thought this came up recently. What can JQuery do that
script.aculo.us can't?

The Jeditable thing that John mentioned is built into scriptaculous
core: http://github.com/madrobby/scriptaculous/wikis/ajax-inplaceeditor

On Dec 17, 2008, at 4:42 PM, Beaudet, David wrote:

>
> I agree that JQuery is probably a better option (in retrospect) than
> Scriptaculous, but who this space has developed so much in the last
> two
> years, there was no way to know... at least it's ajaxified for now.
> Might make a good project to convert to JQuery.
>
>> -----Original Message-----
>> From: John Durkin [mailto:john.durkin [at] gmail]
>> Sent: Wednesday, December 17, 2008 4:36 PM
>> To: devel [at] lists
>> Subject: Re: Bricolage UI Changes
>>
>> Hooray for this discussion. My bricolage install is gradually
> morphing
>> into
>> a strange hybrid of a custom mysql/php cms crossed with bric. I just
>> completed my first bricolage deployment to an entirely CMS-naive
>> blogforce... and while they're good sports, it's tough selling them
>> on
> the
>> UI... a lot of apologizing for the quirkiness, etc.
>> My biggest problem right now is the WYSIWYG contents disappearing
>> when
> you
>> hit "add element" unless you've just hit save and stay... (1.11.1+)
>>
>> My second biggest problem is the arrangement of the save, save and
> stay,
>> check in buttons. I need my users to "check in AND publish" most of
> the
>> time. unfortunately, the big red save button tempts them, and they
> click
>> it
>> instead. if they're doing this on a media item they just created and
> are
>> in
>> the process of relating to a story, they hit save, the window closes,
>> their
>> image is related, but then they go to publish their story and they
>> get
> an
>> error because a related media item is sitting saved on their desk
> instead
>> of
>> having been published.
>>
>> The arrangement of those three buttons and the end of media / story
>> profile
>> pages drives me nuts.
>>
>> jquery is my favorite for ajax - don't think it was out when marshall
> did
>> that work. check out this - jeditable -
>>
>> http://www.appelsiini.net/projects/jeditable
>>
>> must get back to production work - but the UI - IMHO - is the most
>> critical
>> thing we must address to keep bric going...
>>
>> On Wed, Dec 17, 2008 at 8:12 AM, Phillip Smith <
>> phillip [at] communitybandwidth> wrote:
>>
>>>
>>> On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:
>>>
>>>
>>>> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
>>>>
>>>> \Finally, my guess is that many people on this list have opinions
>> about
>>>>> which direction to explore when re-thinking the UI. And, it is
> likely
>> that
>>>>> those opinions will differ greatly. So my preemptive proposal,
> before
>> the
>>>>> conversation gets too far along, is that the process start by
> looking
>> at the
>>>>> existing design patterns out there for similar systems. Perhaps we
> can
>> agree
>>>>> on some general information design / UI layout approaches before
>> getting
>>>>> into specifics?
>>>>>
>>>>
>>>> DSpace has a very nice administrative interface - much more
> integrated
>> and
>>>> automated than our current ui.
>>>>
>>>
>>>
>>> Screenshot?
>>>
>>>
>>> Perhaps we could collect screenshots of UI patterns that we could
> review
>>> and comment on a a group?
>>>
>>>
>>>
>>> --
>>> Phillip Smith // Simplifier of Technology // COMMUNITY
> BANDWIDTH
>>> www.communitybandwidth.ca //
>> www.communitybandwidth.ca/phillipadsmith
>>>
>>>
>>>
>>>
>>>

john.durkin at gmail

Dec 17, 2008, 7:25 PM

Post #17 of 71 (7525 views)
Permalink

Re: Bricolage UI Changes [In reply to]

there probly isn't anything that jquery does that scriptalicious doesn't - i
just only know (a little) jquery... not as familiar with scriptalicious.

On Wed, Dec 17, 2008 at 6:55 PM, Marshall Roch <marshall [at] exclupen>wrote:

> I thought this came up recently. What can JQuery do that script.aculo.uscan't?
>
> The Jeditable thing that John mentioned is built into scriptaculous core:
> http://github.com/madrobby/scriptaculous/wikis/ajax-inplaceeditor
>
>
> On Dec 17, 2008, at 4:42 PM, Beaudet, David wrote:
>
>
>> I agree that JQuery is probably a better option (in retrospect) than
>> Scriptaculous, but who this space has developed so much in the last two
>> years, there was no way to know... at least it's ajaxified for now.
>> Might make a good project to convert to JQuery.
>>
>> -----Original Message-----
>>> From: John Durkin [mailto:john.durkin [at] gmail]
>>> Sent: Wednesday, December 17, 2008 4:36 PM
>>> To: devel [at] lists
>>> Subject: Re: Bricolage UI Changes
>>>
>>> Hooray for this discussion. My bricolage install is gradually
>>>
>> morphing
>>
>>> into
>>> a strange hybrid of a custom mysql/php cms crossed with bric. I just
>>> completed my first bricolage deployment to an entirely CMS-naive
>>> blogforce... and while they're good sports, it's tough selling them on
>>>
>> the
>>
>>> UI... a lot of apologizing for the quirkiness, etc.
>>> My biggest problem right now is the WYSIWYG contents disappearing when
>>>
>> you
>>
>>> hit "add element" unless you've just hit save and stay... (1.11.1+)
>>>
>>> My second biggest problem is the arrangement of the save, save and
>>>
>> stay,
>>
>>> check in buttons. I need my users to "check in AND publish" most of
>>>
>> the
>>
>>> time. unfortunately, the big red save button tempts them, and they
>>>
>> click
>>
>>> it
>>> instead. if they're doing this on a media item they just created and
>>>
>> are
>>
>>> in
>>> the process of relating to a story, they hit save, the window closes,
>>> their
>>> image is related, but then they go to publish their story and they get
>>>
>> an
>>
>>> error because a related media item is sitting saved on their desk
>>>
>> instead
>>
>>> of
>>> having been published.
>>>
>>> The arrangement of those three buttons and the end of media / story
>>> profile
>>> pages drives me nuts.
>>>
>>> jquery is my favorite for ajax - don't think it was out when marshall
>>>
>> did
>>
>>> that work. check out this - jeditable -
>>>
>>> http://www.appelsiini.net/projects/jeditable
>>>
>>> must get back to production work - but the UI - IMHO - is the most
>>> critical
>>> thing we must address to keep bric going...
>>>
>>> On Wed, Dec 17, 2008 at 8:12 AM, Phillip Smith <
>>> phillip [at] communitybandwidth> wrote:
>>>
>>>
>>>> On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:
>>>>
>>>>
>>>> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
>>>>>
>>>>> \Finally, my guess is that many people on this list have opinions
>>>>>
>>>> about
>>>
>>>> which direction to explore when re-thinking the UI. And, it is
>>>>>>
>>>>> likely
>>
>>> that
>>>
>>>> those opinions will differ greatly. So my preemptive proposal,
>>>>>>
>>>>> before
>>
>>> the
>>>
>>>> conversation gets too far along, is that the process start by
>>>>>>
>>>>> looking
>>
>>> at the
>>>
>>>> existing design patterns out there for similar systems. Perhaps we
>>>>>>
>>>>> can
>>
>>> agree
>>>
>>>> on some general information design / UI layout approaches before
>>>>>>
>>>>> getting
>>>
>>>> into specifics?
>>>>>>
>>>>>>
>>>>> DSpace has a very nice administrative interface - much more
>>>>>
>>>> integrated
>>
>>> and
>>>
>>>> automated than our current ui.
>>>>>
>>>>>
>>>>
>>>> Screenshot?
>>>>
>>>>
>>>> Perhaps we could collect screenshots of UI patterns that we could
>>>>
>>> review
>>
>>> and comment on a a group?
>>>>
>>>>
>>>>
>>>> --
>>>> Phillip Smith // Simplifier of Technology // COMMUNITY
>>>>
>>> BANDWIDTH
>>
>>> www.communitybandwidth.ca //
>>>>
>>> www.communitybandwidth.ca/phillipadsmith
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>

D-Beaudet at NGA

Dec 17, 2008, 8:58 PM

Post #18 of 71 (7522 views)
Permalink

RE: Bricolage UI Changes [In reply to]

We use Dojo internally. It's a bit more high-level in functionality than either of JQuery and Scriptaculous, but from what I've listened to on podcasts and read, JQuery is more elegant and is more popular than Scriptaculous, but, that's not to say Scriptaculous isn't up to the job; it's really a question of what's going to be around and supported in five years; the answer might be both, but at this point, if I had to put money on the table, it would be with JQuery. From my experience with vendors who develop software for the Gallery, nobody has mentioned Scriptaculous whereas a number of them have mentioned JQuery.... so that's just more anecdotal evidence. I don't know enough about the internals of either to make a qualitative judgement, but am interested in your opinion on this.

-----Original Message-----
From: John Durkin [mailto:john.durkin [at] gmail]
Sent: Wed 12/17/2008 10:25 PM
To: devel [at] lists
Subject: Re: Bricolage UI Changes

there probly isn't anything that jquery does that scriptalicious doesn't - i
just only know (a little) jquery... not as familiar with scriptalicious.

On Wed, Dec 17, 2008 at 6:55 PM, Marshall Roch <marshall [at] exclupen>wrote:

> I thought this came up recently. What can JQuery do that script.aculo.uscan't?
>
> The Jeditable thing that John mentioned is built into scriptaculous core:
> http://github.com/madrobby/scriptaculous/wikis/ajax-inplaceeditor
>
>
> On Dec 17, 2008, at 4:42 PM, Beaudet, David wrote:
>
>
>> I agree that JQuery is probably a better option (in retrospect) than
>> Scriptaculous, but who this space has developed so much in the last two
>> years, there was no way to know... at least it's ajaxified for now.
>> Might make a good project to convert to JQuery.
>>
>> -----Original Message-----
>>> From: John Durkin [mailto:john.durkin [at] gmail]
>>> Sent: Wednesday, December 17, 2008 4:36 PM
>>> To: devel [at] lists
>>> Subject: Re: Bricolage UI Changes
>>>
>>> Hooray for this discussion. My bricolage install is gradually
>>>
>> morphing
>>
>>> into
>>> a strange hybrid of a custom mysql/php cms crossed with bric. I just
>>> completed my first bricolage deployment to an entirely CMS-naive
>>> blogforce... and while they're good sports, it's tough selling them on
>>>
>> the
>>
>>> UI... a lot of apologizing for the quirkiness, etc.
>>> My biggest problem right now is the WYSIWYG contents disappearing when
>>>
>> you
>>
>>> hit "add element" unless you've just hit save and stay... (1.11.1+)
>>>
>>> My second biggest problem is the arrangement of the save, save and
>>>
>> stay,
>>
>>> check in buttons. I need my users to "check in AND publish" most of
>>>
>> the
>>
>>> time. unfortunately, the big red save button tempts them, and they
>>>
>> click
>>
>>> it
>>> instead. if they're doing this on a media item they just created and
>>>
>> are
>>
>>> in
>>> the process of relating to a story, they hit save, the window closes,
>>> their
>>> image is related, but then they go to publish their story and they get
>>>
>> an
>>
>>> error because a related media item is sitting saved on their desk
>>>
>> instead
>>
>>> of
>>> having been published.
>>>
>>> The arrangement of those three buttons and the end of media / story
>>> profile
>>> pages drives me nuts.
>>>
>>> jquery is my favorite for ajax - don't think it was out when marshall
>>>
>> did
>>
>>> that work. check out this - jeditable -
>>>
>>> http://www.appelsiini.net/projects/jeditable
>>>
>>> must get back to production work - but the UI - IMHO - is the most
>>> critical
>>> thing we must address to keep bric going...
>>>
>>> On Wed, Dec 17, 2008 at 8:12 AM, Phillip Smith <
>>> phillip [at] communitybandwidth> wrote:
>>>
>>>
>>>> On 17-Dec-08, at 11:03 AM, Matt Rolf wrote:
>>>>
>>>>
>>>> On Dec 17, 2008, at 10:15 AM, Phillip Smith wrote:
>>>>>
>>>>> \Finally, my guess is that many people on this list have opinions
>>>>>
>>>> about
>>>
>>>> which direction to explore when re-thinking the UI. And, it is
>>>>>>
>>>>> likely
>>
>>> that
>>>
>>>> those opinions will differ greatly. So my preemptive proposal,
>>>>>>
>>>>> before
>>
>>> the
>>>
>>>> conversation gets too far along, is that the process start by
>>>>>>
>>>>> looking
>>
>>> at the
>>>
>>>> existing design patterns out there for similar systems. Perhaps we
>>>>>>
>>>>> can
>>
>>> agree
>>>
>>>> on some general information design / UI layout approaches before
>>>>>>
>>>>> getting
>>>
>>>> into specifics?
>>>>>>
>>>>>>
>>>>> DSpace has a very nice administrative interface - much more
>>>>>
>>>> integrated
>>
>>> and
>>>
>>>> automated than our current ui.
>>>>>
>>>>>
>>>>
>>>> Screenshot?
>>>>
>>>>
>>>> Perhaps we could collect screenshots of UI patterns that we could
>>>>
>>> review
>>
>>> and comment on a a group?
>>>>
>>>>
>>>>
>>>> --
>>>> Phillip Smith // Simplifier of Technology // COMMUNITY
>>>>
>>> BANDWIDTH
>>
>>> www.communitybandwidth.ca //
>>>>
>>> www.communitybandwidth.ca/phillipadsmith
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>

david at kineticode

Dec 18, 2008, 5:31 AM

Post #19 of 71 (7521 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 3:29 PM, Matt Rolf wrote:

> Over here at Denison we've talked about making changes to the
> Bricolage UI. Most of these changes revolve around streamlining the
> story profile or admin sections.
>
> Let's start with the story profile. The *vast* majority of our
> users just care about the content section. They do not change
> output channels, they don't add or subtract contributors, and they
> rarely change category. Ideally, we feel that the initial view of
> the story profile should be stripped down to just the content
> section, the preview link, and the controlling links. It would be
> similar to the old element profile screen, but even more stripped
> down.

Hrm. Maybe a reveal icon to show the other stuff, but have it hidden
by default, eh? That way we keep it there for those who need it, but
it's out of the way for those who don't.

> How could that be accomplished? One idea that we have had is
> eliminating the breadcrumbs at the top of the page since they are
> not very useful in practice, and replacing them with app-style
> dropdown menus. Clicking on one could show a hidden div with the
> interface window for . So we'd have
>
> Information
> Categories
> Output Channels
> Contributors
> Keywords
>
> And you could even break down the information one more into one or
> two more tabs.

That's not a bad idea. Take a look at how this is done for the
permissions screen. The layout should be the same (although, unlike
permissions, there should be no reload to show the selected section(s).

> Regarding the Admin section, every single initial page is a search
> box with a results list below it - quite simple, really. We've
> toyed with the idea of moving the menu up to the top of the screen -
> placing Admin, Publishing, and Distribution directly below the
> MyWorkSpace link, and then placing the submenus along the top of the
> screen as opposed to being a drop down. At some level it's just
> moving things around, but it would make it more natural to the user
> by being at the top, and its location less subject to how many
> workflows are in a typical install. After that, I think there's
> work that could be done to style those aspects of the interface and
> make them more sexy.

I don't think the admin tools should be at the top or in a drop-down.
For the vast majority of users, the workflows are much more important
than the admin tools.

> Obviously these changes aren't going to make it into 2.0 even if we
> develop them to the point of good ideas, but what we would like to
> explore for 2.0 is putting the majority of the "Information" section
> into a div that gets shown or hidden much like the advanced search
> feature now does in 2.0. It looks like it would be relatively
> simple to do, and would keep Bricolage trainers from having to tell
> users to "scroll down" every time they want to do something.

Sure. Can you do it by tomorrow? ;-)

> I'm interested to hear what others think - I know that Mr. Lanning
> in particular has recently voiced frustration with the ui. So let's
> start a discussion about where we want to take the ui in the future.
>
> As an aside, the Bricolage CSS is a nightmare - you know the
> Seinfeld episode where Jackie is trying to sue the cigarette
> companies and describes Kramer as a goblin? Yeah, that. The main
> css file is 27kb and overloaded with selectors that are overly
> specific and far too many !importants. We found out just how
> difficult it was to work with when we redid the desk-item buttons.
> I recently reorganized the Denison CSS (which was a lurching
> monstrosity in its own right) along the lines of this blog entry -
>
> http://meiert.com/en/blog/20080515/css-organization-and-efficiency/
>
> Following a lot of the guidelines, we cut our CSS size by about 60%
> and made it much more readable. If nobody has objection, I'll take
> a stab at the bricolage css in the same manner in the near future.
> That would would make future UI changes easier to implement.

+1

Best,

David

david at kineticode

Dec 18, 2008, 5:32 AM

Post #20 of 71 (7528 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 3:58 PM, Beaudet, David wrote:

> I'd welcome these as a start. I'd also like to see more information
> about story status in search results... the content of the information
> could easily be richer than this
>
> http://www.flickr.com/photos/beaudet/465261462/sizes/l/
>
> but laid out in a way that makes better use of real-estate... or for
> some of it, with pop-ups for information that's not important for page
> scanning purposes... such as the live links... actually, that would
> make
> a great pop-up... put the live link inside a pop-up div when someone
> clicks on it.

Sure. Mockups welcome, BTW.

Best,

David

david at kineticode

Dec 18, 2008, 6:06 AM

Post #21 of 71 (7543 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 4:23 PM, Scott Lanning wrote:

>> Obviously these changes aren't going to make it into 2.0 even if
>> we develop them to the point of good ideas,
>
> It's not obvious to me.

Feature freeze is tomorrow.

> I personally won't be satisfied until Bricolage turns
> into a 3D-game interface. I still think the idea of
> harpooning whales as a metaphor for related links could work.

Hey, at least you can use it to send email! :-)

David

david at kineticode

Dec 18, 2008, 6:16 AM

Post #22 of 71 (7535 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 5:06 PM, Matt Rolf wrote:

>>> One idea that we have had is eliminating the breadcrumbs at the top
>>> of the page [...] and replacing them with app-style dropdown menus.
>>
>> Not sure what you mean by app-style dropdown menus.
>
> Similar to those on the toolbar of a mac.

Um, no.

http://billhiggins.us/weblog/2007/05/17/the-uncanny-valley-of-user-interface-design/

From that article:

In more concrete terms: a Windows application should look and feel
like a Windows application, a Mac application should look and feel
like a Mac application, and a web application should look and feel
like a web application.

>> It's not obvious to me.
>
> Well, there was talk of a feature freeze taking place in two days.
> I'm not sure how I feel about rolling in major ui changes in
> addition to what we've got in that version - my immediate reaction
> is to push it to the next release.

We're having enough trouble polishing the bugs off the current UI
changes (to mix metaphors a bit).

>> Out back and shot? Mais, non.
>
> That is a good idea.

Time for a new CMS? ;-P

Best,

David

david at kineticode

Dec 18, 2008, 6:18 AM

Post #23 of 71 (7519 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 17, 2008, at 10:35 PM, John Durkin wrote:

> Hooray for this discussion. My bricolage install is gradually
> morphing into
> a strange hybrid of a custom mysql/php cms crossed with bric. I just
> completed my first bricolage deployment to an entirely CMS-naive
> blogforce... and while they're good sports, it's tough selling them
> on the
> UI... a lot of apologizing for the quirkiness, etc.
> My biggest problem right now is the WYSIWYG contents disappearing
> when you
> hit "add element" unless you've just hit save and stay... (1.11.1+)

Bug.

> The arrangement of those three buttons and the end of media / story
> profile
> pages drives me nuts.

Well, it'd be difficult to please all the people with a single
solution. Unless we come up with something completely different.
Suggestions welcome.

> jquery is my favorite for ajax - don't think it was out when
> marshall did
> that work. check out this - jeditable -
>
> http://www.appelsiini.net/projects/jeditable

Yeah, we did something like this with early versions of Stikkit.

> must get back to production work - but the UI - IMHO - is the most
> critical
> thing we must address to keep bric going...

Agreed.

Best,

David

david at kineticode

Dec 18, 2008, 6:20 AM

Post #24 of 71 (7513 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 18, 2008, at 5:58 AM, Beaudet, David wrote:

> We use Dojo internally. It's a bit more high-level in functionality
> than either of JQuery and Scriptaculous, but from what I've listened
> to on podcasts and read, JQuery is more elegant and is more popular
> than Scriptaculous, but, that's not to say Scriptaculous isn't up to
> the job; it's really a question of what's going to be around and
> supported in five years; the answer might be both, but at this
> point, if I had to put money on the table, it would be with JQuery.
> From my experience with vendors who develop software for the
> Gallery, nobody has mentioned Scriptaculous whereas a number of them
> have mentioned JQuery.... so that's just more anecdotal evidence. I
> don't know enough about the internals of either to make a
> qualitative judgement, but am interested in your opinion on this.

This whole discussion is beside the point. We're not going to rewrite
the UI to a different Ajax library anytime soon.

Best,

David

rolfm at denison

Dec 18, 2008, 7:39 AM

Post #25 of 71 (7528 views)
Permalink

Re: Bricolage UI Changes [In reply to]

On Dec 18, 2008, at 8:31 AM, David E. Wheeler wrote:

> Hrm. Maybe a reveal icon to show the other stuff, but have it hidden
> by default, eh? That way we keep it there for those who need it, but
> it's out of the way for those who don't.

Yep.

>> How could that be accomplished? One idea that we have had is
>> eliminating the breadcrumbs at the top of the page since they are
>> not very useful in practice, and replacing them with app-style
>> dropdown menus. Clicking on one could show a hidden div with the
>> interface window for . So we'd have
>>
>> Information
>> Categories
>> Output Channels
>> Contributors
>> Keywords
>>
>> And you could even break down the information one more into one or
>> two more tabs.
>
> That's not a bad idea. Take a look at how this is done for the
> permissions screen. The layout should be the same (although, unlike
> permissions, there should be no reload to show the selected
> section(s).

Ah, you mean like the drop down menu?

> I don't think the admin tools should be at the top or in a drop-
> down. For the vast majority of users, the workflows are much more
> important than the admin tools.

It is not important, true. But there's something to be said for
always knowing where it is going to be.
>
>
>> Obviously these changes aren't going to make it into 2.0 even if we
>> develop them to the point of good ideas, but what we would like to
>> explore for 2.0 is putting the majority of the "Information"
>> section into a div that gets shown or hidden much like the advanced
>> search feature now does in 2.0. It looks like it would be
>> relatively simple to do, and would keep Bricolage trainers from
>> having to tell users to "scroll down" every time they want to do
>> something.
>
> Sure. Can you do it by tomorrow? ;-)

I'll work on it - it may be late tomorrow, PST.

>> Following a lot of the guidelines, we cut our CSS size by about 60%
>> and made it much more readable. If nobody has objection, I'll take
>> a stab at the bricolage css in the same manner in the near future.
>> That would would make future UI changes easier to implement.
>
> +1

All right, I'll take a look at it.

-Matt

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads