Last mockup of the day. This one is for that elusive plugin page. In this particular instance, i've gone in the COMPLETE opposite direction of my previous mockups. In this particular mockup, the plugin page extends the entire width of the actual page. The more I thought about the manage content pages, both the comments and the posts I thought that if we didn't solve this in a holistic fashion we would have a bit of trouble. In this particular case all the information is found on the page, in a single row. if a plugin has configuration options then they are shown. If the plugin is disabled then it's greyed out and there is no configuration link. The update link is also there as well within the column. Links directly to the plugin author's page, or even the download link directly?
Select all is at the top of the tick boxes. Which are all controlled by the control bar that sits underneath the subtitle bar. You can therefore activate or disable plugins in bulk (of course with all the necessary warning etc). On the right hand side, we've got the filter page drop down menu which lets us see all the disabled/enabled plugins.
Those users that have smaller screens won't get too penalised in that the description might force text to wrap, but that's ok everything is completely usable still for them.
The control bar concept can then be used for the manage content/post page as well and where ever else we need it.
> Last mockup of the day. This one is for that elusive plugin page. In > this particular instance, i've gone in the COMPLETE opposite direction > of my previous mockups. In this particular mockup, the plugin page > extends the entire width of the actual page. The more I thought about > the manage content pages, both the comments and the posts I thought > that if we didn't solve this in a holistic fashion we would have a bit > of trouble. In this particular case all the information is found on > the page, in a single row. if a plugin has configuration options then > they are shown. If the plugin is disabled then it's greyed out and > there is no configuration link. The update link is also there as well > within the column. Links directly to the plugin author's page, or even > the download link directly?
> Select all is at the top of the tick boxes. Which are all controlled > by the control bar that sits underneath the subtitle bar. You can > therefore activate or disable plugins in bulk (of course with all the > necessary warning etc). On the right hand side, we've got the filter > page drop down menu which lets us see all the disabled/enabled plugins.
> Those users that have smaller screens won't get too penalised in that > the description might force text to wrap, but that's ok everything is > completely usable still for them.
> The control bar concept can then be used for the manage content/post > page as well and where ever else we need it.
I'm with Michael. It seems way to cluttered. Also, I'm not too thrilled about the fluid width, especially since it seems to stretch across 100% of the screen -- as your resolution already demonstrates, it can get a bit unusable. Something simpler would be better, IMO.
On Jan 14, 2008 1:30 PM, Michael Heilemann <heilem...@gmail.com> wrote:
> On Jan 14, 2008 10:26 PM, Khaled Abou Alfa < brokenk...@gmail.com> wrote:
> > Okay then,
> > Last mockup of the day. This one is for that elusive plugin page. In > > this particular instance, i've gone in the COMPLETE opposite direction > > of my previous mockups. In this particular mockup, the plugin page > > extends the entire width of the actual page. The more I thought about > > the manage content pages, both the comments and the posts I thought > > that if we didn't solve this in a holistic fashion we would have a bit > > of trouble. In this particular case all the information is found on > > the page, in a single row. if a plugin has configuration options then > > they are shown. If the plugin is disabled then it's greyed out and > > there is no configuration link. The update link is also there as well > > within the column. Links directly to the plugin author's page, or even > > the download link directly?
> > Select all is at the top of the tick boxes. Which are all controlled > > by the control bar that sits underneath the subtitle bar. You can > > therefore activate or disable plugins in bulk (of course with all the > > necessary warning etc). On the right hand side, we've got the filter > > page drop down menu which lets us see all the disabled/enabled plugins.
> > Those users that have smaller screens won't get too penalised in that > > the description might force text to wrap, but that's ok everything is > > completely usable still for them.
> > The control bar concept can then be used for the manage content/post > > page as well and where ever else we need it.
Michael, I like your plugin page design, except for my already stated opposition to the use of colours as UI elements.
Khaled, one element I don't like is that "Update" obscures the current version number. I find there are often times when I don't want to update, even though an update is available.
> Michael, I like your plugin page design, except for my already stated > opposition to the use of colours as UI elements.
Perhaps I didn't read the previous threads thoroughly enough, but I haven't been convinced there's a valid reason against colors in the admin. AFAIK, it can be done that the colors are distinct enough, even to people with mild colorblindness, which IMO is good enough.
On Mon, Jan 14, 2008 at 10:57:49PM -0800, Robin Adrianse wrote: > On Jan 14, 2008 4:31 PM, Michael C. Harris > <[1]michael.twof...@gmail.com> wrote:
> On Mon, Jan 14, 2008 at 10:30:24PM +0100, Michael Heilemann wrote: > > I'm afraid I'll cling on to this for
> > now: [1]http://flickr.com/photos/heilemann/2183367609/ :| > Michael, I like your plugin page design, except for my already > stated > opposition to the use of colours as UI elements.
> Perhaps I didn't read the previous threads thoroughly enough, but I > haven't been convinced there's a valid reason against colors in the > admin. AFAIK, it can be done that the colors are distinct enough, even > to people with mild colorblindness, which IMO is good enough.
I'm strongly against colour as a UI element. This is what I wrote earlier.
> I'm not talking about what's universally accepted, I'm talking about > how I personally interact with a UI (and with colour in general). A > UI should be as intuitive as possible (leaving aside recent > arguments elsewhere regarding the meaning of intuitive). You're > making the assumption that green == active through go is intuitive, > and to me it isn't.
> I mention my colour blindness because that's likely the reason I > don't relate to colour-based UI elements in the way that you expect. > Of course I worked it out, and I'd be fine with it now, but because > of the extra cognitive effort that I have to make with colour-based > UI elements, my initial reaction was negative.
Not to be disrespectful or anything, but I don't think we should limit our UI decisions based upon a condition that 1.4% of the world ( http://en.wikipedia.org/wiki/Color_blindness#Prevalence) suffers from, and even then in various "subsets" (don't know the specific terminology) of colorblindness (e.g. can't see red/green, a type of cone missing). While it may be something we should take into consideration and keep in mind, I strongly feel that we shouldn't limit our options based upon this argument.
On Jan 14, 2008 11:42 PM, Michael C. Harris <michael.twof...@gmail.com> wrote:
> On Mon, Jan 14, 2008 at 10:57:49PM -0800, Robin Adrianse wrote: > > On Jan 14, 2008 4:31 PM, Michael C. Harris > > <[1]michael.twof...@gmail.com> wrote:
> > On Mon, Jan 14, 2008 at 10:30:24PM +0100, Michael Heilemann wrote: > > > I'm afraid I'll cling on to this for
> > > now: [1]http://flickr.com/photos/heilemann/2183367609/ :| > > Michael, I like your plugin page design, except for my already > > stated > > opposition to the use of colours as UI elements.
> > Perhaps I didn't read the previous threads thoroughly enough, but I > > haven't been convinced there's a valid reason against colors in the > > admin. AFAIK, it can be done that the colors are distinct enough, > even > > to people with mild colorblindness, which IMO is good enough.
> I'm strongly against colour as a UI element. This is what I wrote > earlier.
> > I'm not talking about what's universally accepted, I'm talking about > > how I personally interact with a UI (and with colour in general). A > > UI should be as intuitive as possible (leaving aside recent > > arguments elsewhere regarding the meaning of intuitive). You're > > making the assumption that green == active through go is intuitive, > > and to me it isn't.
> > I mention my colour blindness because that's likely the reason I > > don't relate to colour-based UI elements in the way that you expect. > > Of course I worked it out, and I'd be fine with it now, but because > > of the extra cognitive effort that I have to make with colour-based > > UI elements, my initial reaction was negative.
On Mon, Jan 14, 2008 at 11:52:29PM -0800, Robin Adrianse wrote: > Not to be disrespectful or anything, but I don't think we should limit > our UI decisions based upon a condition that 1.4% of the world > ([1]http://en.wikipedia.org/wiki/Color_blindness#Prevalence ) suffers > from, and even then in various "subsets" (don't know the specific > terminology) of colorblindness (e.g. can't see red/green, a type of > cone missing).
> While it may be something we should take into consideration and keep in > mind, I strongly feel that we shouldn't limit our options based upon > this argument.
Well, it's all subjective. I've made my point that for me this is not an intuitive UI. I also don't think it's necessary to use colour - there are other ways to convey the meaning (that are clearer for me but I can't speak for anyone else). The use of colour feels a bit jarring and out of keeping here as well, but again that's subjective.
In the discussion of color vs. no color, two things are worth considering:
First of all, to my knowledge no decisions was ever made to avoid colors at all costs. And since I was the one who pitched and defended the currently monotone color space, I feel I ought to know. Colors are extremely powerful for about 98.6% of the world's population; they're worth using.
But, secondly, I agree with Michael Harris. The current use of green/red on the plugins page is not particularly effective. That is my mistake; I had overlooked the basic rule of color use, enforcing colors with shapes and position. My mistake.
But until I have the time to reinforce my mockup, forget you ever saw it, and instead tell Khaled what you think of his, because that's what this thread is about.
My only concern here is the way the plugins are activated/deactivated in this suggestion. This definitely facilitate doing so for multiple plugins. But each time you want to activate/deactivate single plugin, you would have to go and check it, and then you click on the activate button. My question is, which one do you think is done more often, activating/deactivating a single plugin, or more than one?
On Jan 14, 2008 11:26 PM, Khaled Abou Alfa <brokenk...@gmail.com> wrote:
> Last mockup of the day. This one is for that elusive plugin page. In > this particular instance, i've gone in the COMPLETE opposite direction > of my previous mockups. In this particular mockup, the plugin page > extends the entire width of the actual page. The more I thought about > the manage content pages, both the comments and the posts I thought > that if we didn't solve this in a holistic fashion we would have a bit > of trouble. In this particular case all the information is found on > the page, in a single row. if a plugin has configuration options then > they are shown. If the plugin is disabled then it's greyed out and > there is no configuration link. The update link is also there as well > within the column. Links directly to the plugin author's page, or even > the download link directly?
> Select all is at the top of the tick boxes. Which are all controlled > by the control bar that sits underneath the subtitle bar. You can > therefore activate or disable plugins in bulk (of course with all the > necessary warning etc). On the right hand side, we've got the filter > page drop down menu which lets us see all the disabled/enabled plugins.
> Those users that have smaller screens won't get too penalised in that > the description might force text to wrap, but that's ok everything is > completely usable still for them.
> The control bar concept can then be used for the manage content/post > page as well and where ever else we need it.
-- Ali B.
"No one can make you feel inferior without your consent." -- Eleanor Roosevelt
> Well, it's all subjective. I've made my point that for me this is not > an intuitive UI. I also don't think it's necessary to use colour - > there are other ways to convey the meaning (that are clearer for me > but I can't speak for anyone else). The use of colour feels a bit > jarring and out of keeping here as well, but again that's subjective.
The use of color per sé isn't subjective. It's a well-proven element of interaction design. In a medium where the communication bandwidth is relatively low, colors are immensely effective.
And it's not whether or not it is 'necessary'; it's a case of how is something conveyed as fast and unambiguously as possible, while retaining stylistic integrity and usability.
Robin Adrianse wrote: > Not to be disrespectful or anything, but I don't think we should limit > our UI decisions based upon a condition that 1.4% of the world > (http://en.wikipedia.org/wiki/Color_blindness#Prevalence > <http://en.wikipedia.org/wiki/Color_blindness#Prevalence>) suffers from, > and even then in various "subsets" (don't know the specific terminology) > of colorblindness (e.g. can't see red/green, a type of cone missing).
Without really taking part in the color/non-color discussion: The article you linked states "Color blindness affects a significant number of people" and gives figures of "In the United States, about 7 percent of the male population – or about 10.5 million men – and 0.4 percent of the female population".
1.4% of 6.6 billion people is still 92.4 million people.
> I don't think this a good support for the point you're making.
> Do signs that were designed with colors suck when desaturated? Yes. > Could you design the signs in a way they would not require color? Yes.
They could, but their effectiveness would be _considerably_ less. Viewed from a distance, or in the blink of an eye, a color will tell you much more than a shape or a string of text will.
> Also note how none of those uses red/green. The only place that's used > in traffic is traffic lights.
The discussion wasn't _which_ colors. Simply colors.
On Tue, Jan 15, 2008 at 12:50:22PM +0100, Michael Heilemann wrote: > Well, it's all subjective. I've made my point that for me this is > not > an intuitive UI. I also don't think it's necessary to use colour - > there are other ways to convey the meaning (that are clearer for me > but I can't speak for anyone else). The use of colour feels a bit > jarring and out of keeping here as well, but again that's > subjective.
> The use of color per sé isn't subjective. It's a well-proven element of > interaction design. In a medium where the communication bandwidth is > relatively low, colors are immensely effective. > And it's not whether or not it is 'necessary'; it's a case of how is > something conveyed as fast and unambiguously as possible, while > retaining stylistic integrity and usability. > I think a few hundred years of roadside sign design is on my side: > [1]http://flickr.com/photos/heilemann/2195083538/.
I'm glad everyone feels they need to find or create links to tell me I'm wrong, but it doesn't change the fact that the presented design doesn't work for me. There is _obviously_ some level of subjectivity here.
On Wed, Jan 16, 2008 at 02:04:25PM +1100, Michael C. Harris wrote: > On Tue, Jan 15, 2008 at 12:50:22PM +0100, Michael Heilemann wrote: > > Well, it's all subjective. I've made my point that for me this is > > not > > an intuitive UI. I also don't think it's necessary to use colour - > > there are other ways to convey the meaning (that are clearer for me > > but I can't speak for anyone else). The use of colour feels a bit > > jarring and out of keeping here as well, but again that's > > subjective.
> > The use of color per sé isn't subjective. It's a well-proven element of > > interaction design. In a medium where the communication bandwidth is > > relatively low, colors are immensely effective. > > And it's not whether or not it is 'necessary'; it's a case of how is > > something conveyed as fast and unambiguously as possible, while > > retaining stylistic integrity and usability. > > I think a few hundred years of roadside sign design is on my side: > > [1]http://flickr.com/photos/heilemann/2195083538/.
> I'm glad everyone feels they need to find or create links to tell me > I'm wrong, but it doesn't change the fact that the presented design > doesn't work for me. There is _obviously_ some level of subjectivity > here.
While saying that, I just want to make it clear that I cede to your design skills, and fully recognise that design by committee is not possible. I'm not pretending to be a designer, I'm simply stating how I feel about the design element.
On Jan 15, 2008 10:37 PM, Michael C. Harris <michael.twof...@gmail.com> wrote:
> While saying that, I just want to make it clear that I cede to your > design skills, and fully recognise that design by committee is not > possible. I'm not pretending to be a designer, I'm simply stating how > I feel about the design element.
