here are 2 proposals for the new article edit screen with the new design
applied. The new grouping and positioning of elements is open
for discussion so any suggestions and fresh ideas are welcome.
Just a small explanation of some basic functionality:
• all the panels on the right are collapsible
• the bar with the article name and "Save all" and "Save & Close" buttons
will stick on top of the browser window when the page is scrolled down,
enabling easy access to the Save buttons.
Posts: 113Member, Administrator, Sourcefabric Team
Hi Fritz,
This looks very good and very promising. I'd definitely prefer the first variant
re: scheduled publishing (on the right).
All the best,
Sava
On Thursday, December 16, 2010 16:08:05 you wrote:
> Hi everybody,
>
> here are 2 proposals for the new article edit screen with the new design
> applied. The new grouping and positioning of elements is open
> for discussion so any suggestions and fresh ideas are welcome.
> Just a small explanation of some basic functionality:
> • all the panels on the right are collapsible
> • the bar with the article name and "Save all" and "Save & Close" buttons
> will stick on top of the browser window when the page is scrolled down,
> enabling easy access to the Save buttons.
>
> Waiting to hear your comments :)
> Best, Fritz
These are a _huge_ improvement over what was there before. I like the overall consistency, especially with the look of the widgets on the front page. Do you envision that, like the front page widgets, users will be able to reorder the items in the second column?
doug
Douglas Arellanes Director of Innovation Sourcefabric, o.p.s.
> Hi Fritz,
>
> These are a _huge_ improvement over what was there before. I like the
> overall consistency, especially with the look of the widgets on the front
> page. Do you envision that, like the front page widgets, users will be able
> to reorder the items in the second column?
>
> doug
>
You are right, not for 3.5, to provide that means not only UI changes
but also in code. But yeah, for a further release it might be
implemented, create a ticket please. Thanks.
On Thu, Dec 16, 2010 at 4:56 PM, Vladimir Stefanovic
<campsite-dev@lists.sourcefabric.org> wrote:
>
> Thanks Doug,
> making users able to reorder the panels on the right is the idea, although
> not sure if it will be available for the first relese.
>
> fritz
>
>
> On 16 December 2010 16:45, Douglas Arellanes <
> campsite-dev@lists.sourcefabric.org> wrote:
>
> > Hi Fritz,
> >
> > These are a _huge_ improvement over what was there before. I like the
> > overall consistency, especially with the look of the widgets on the front
> > page. Do you envision that, like the front page widgets, users will be able
> > to reorder the items in the second column?
> >
> > doug
> >
>
>
>
> --
> Vladimir Stefanović
> *Interface Design and Usability, Sourcefabric*
> vladimir.stefanovic@sourcefabric.org
>
> Belgrade, Serbia
> +381 (0)64 156 2356
> Skype: fritzaman
>
> Subscribe to our Newsletter:
> www.sourcefabric.org/newsletter/
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
here is a minor revision of the screens sent before. This are the changes:
1. the bar with the article name and save buttons has been tweaked and
aligned better
2. we decided to get rid of some frames inside the main edit box.
Also attached is a screen that should make how the "floating" bar with save
buttons will function if the page is scrolled down
(Article-Edit-3c_scrolled_page.png).
> Hi Fritz,
>
> This looks very good and very promising. I'd definitely prefer the first
> variant
> re: scheduled publishing (on the right).
>
> All the best,
>
> Sava
>
> On Thursday, December 16, 2010 16:08:05 you wrote:
> > Hi everybody,
> >
> > here are 2 proposals for the new article edit screen with the new design
> > applied. The new grouping and positioning of elements is open
> > for discussion so any suggestions and fresh ideas are welcome.
> > Just a small explanation of some basic functionality:
> > • all the panels on the right are collapsible
> > • the bar with the article name and "Save all" and "Save & Close" buttons
> > will stick on top of the browser window when the page is scrolled down,
> > enabling easy access to the Save buttons.
> >
> > Waiting to hear your comments :)
> > Best, Fritz
>
> --
> Sava Tatić
> Managing Director, Sourcefabric o.p.s.
> sava.tatic@sourcefabric.org
>
> Salvátorská 10
> 110 00 Praha 1, Czech Republic
> +420222362540
> +420602653104 (mobile)
> Skype: tictactatic
>
> Subscribe to our Newsletter:
> www.sourcefabric.org/newsletter/
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
>
well, in general I like that the layout is very clean and intuitive, as an editor I know exactly where i'm and how to get to other parts of my publication as well as within the article.
I would suggest, however, while we can make the right modules "drag and drop", to consider the following order for those boxes:
publish schedule
media
keywords
switches
info
location
can we do that at his moment or was that not open to change???...my suggestion comes from my times as editor...have them prioritize in order of what is used more often.
something else, am i not interpreting right this "forever on top" save bar or does this modality hides/supersedes the two top menus??? because if so, i wouldn't recomend it...editors/reporters are always bz/running and as dumb as it sounds if they lose that anchor of "where i am" menu while scrolling down it might get confusing...
thanks for your feedback. The position of the modules on the right is open
for discussion, especially because the "drag and drop" feature will not be
available at first. Any suggestion from the user point of view is more then
welcome.
The save bar would stick to the top of the browser if scrolled down,
everything else would scroll down, as it does now. One solution would be to
leave the breadcrumb bar also. This is definitely something that we should
test on a html mock-up before making a final decision.
> Hi Fritz,
>
>
> well, in general I like that the layout is very clean and intuitive, as an
> editor I know exactly where i'm and how to get to other parts of my
> publication as well as within the article.
>
> I would suggest, however, while we can make the right modules "drag and
> drop", to consider the following order for those boxes:
>
> publish schedule
> media
> keywords
> switches
> info
> location
>
> can we do that at his moment or was that not open to change???...my
> suggestion comes from my times as editor...have them prioritize in order of
> what is used more often.
>
> something else, am i not interpreting right this "forever on top" save bar
> or does this modality hides/supersedes the two top menus??? because if so, i
> wouldn't recomend it...editors/reporters are always bz/running and as dumb
> as it sounds if they lose that anchor of "where i am" menu while scrolling
> down it might get confusing...
>
>
> -ccruz
>
>
Another piece of feedback I wanted to give is that certain, more important
functions, like the save button, should probably be made a lot more
prominent. The save button looks a little small to me right now.
The same is true for the article name. I'd prefer to see that at least a
couple of point sizes bigger.
> Hi Claudia,
>
> thanks for your feedback. The position of the modules on the right is open
> for discussion, especially because the "drag and drop" feature will not be
> available at first. Any suggestion from the user point of view is more then
> welcome.
>
> The save bar would stick to the top of the browser if scrolled down,
> everything else would scroll down, as it does now. One solution would be to
> leave the breadcrumb bar also. This is definitely something that we should
> test on a html mock-up before making a final decision.
>
> fritz
>
>
> On 17 December 2010 06:34, Claudia Cruz <
> campsite-dev@lists.sourcefabric.org
>
> > wrote:
>
> > Hi Fritz,
> >
> >
> > well, in general I like that the layout is very clean and intuitive, as
> an
> > editor I know exactly where i'm and how to get to other parts of my
> > publication as well as within the article.
> >
> > I would suggest, however, while we can make the right modules "drag and
> > drop", to consider the following order for those boxes:
> >
> > publish schedule
> > media
> > keywords
> > switches
> > info
> > location
> >
> > can we do that at his moment or was that not open to change???...my
> > suggestion comes from my times as editor...have them prioritize in order
> of
> > what is used more often.
> >
> > something else, am i not interpreting right this "forever on top" save
> bar
> > or does this modality hides/supersedes the two top menus??? because if
> so, i
> > wouldn't recomend it...editors/reporters are always bz/running and as
> dumb
> > as it sounds if they lose that anchor of "where i am" menu while
> scrolling
> > down it might get confusing...
> >
> >
> > -ccruz
> >
> >
>
>
>
> --
> Vladimir Stefanović
> *Interface Design and Usability, Sourcefabric*
> vladimir.stefanovic@sourcefabric.org
>
> Belgrade, Serbia
> +381 (0)64 156 2356
> Skype: fritzaman
>
> Subscribe to our Newsletter:
> www.sourcefabric.org/newsletter/
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
>
Hi all,
I very much agree with Doug that this is a huge improvement over what
was there before.
Unfortunately, I am not very happy with consistency on the page. My
first few seconds impression was that the use of blue color as a
contrast is not very clear. I was expecting that all blue text is
clickable text with some function (article title, post a comment
title, etc..). Also 'Edit' function does not follow consistency/
repetition principle. It start's as blue text and one inch below is
grey square button.
Position of 'Article list' button is not placed very logically. It is
a kind of navigation button which will take you away form the Article
Edit page and should not brake any article filed from others (In this
case article title).
I also think the main box on the left with article fields are not
following overall IA strategy on the page. Those basic and
'fundamental' fields do not need to be in one box but could be in a
separate boxes. As a most important part of the Article Edit page it
is still the same as it was before. Field titles like Deck, Lead/SMS,
Body do not need to take so much space on the left. For example if you
put it above the field (in a same style as other boxes) you will get
more space for the text editor and everyone who is writing there or
maintaining the publication will be very grateful for that (from
personal experience :) ).
As Sava, I also think the place for scheduled publishing is not ideal
one but if it goes right it should not be "drag and drop". Maybe it
could be placed on the right of the author and photographer and get
the 'premium' place in the left bar. I would like to suggest, apart of
blue color, to use a size or some other technics a bit as contrast to
point importance of different features. Also, you may consider to
colorize symbol eks (x) for delete in some warning color as red (at
least on mouse over), especially because CS does not have recycle-bin/
trash function.
All in all, you have done very good work Fritz. Thanks.
All the best,
kiza
On Dec 16, 2010, at 4:45 PM, Douglas Arellanes wrote:
>
> Hi Fritz,
>
> These are a _huge_ improvement over what was there before. I like
> the overall consistency, especially with the look of the widgets on
> the front page. Do you envision that, like the front page widgets,
> users will be able to reorder the items in the second column?
>
> doug
>
Posts: 113Member, Administrator, Sourcefabric Team
The breadcrubs not scrolling down is not a bad idea. We should try it.
Re: ordrer, Claudia, when you were an editor, there were no Locations. We put
them up there because we thought it'd be important to capture this information
at article-writing time. And the logic was to have a variant of the classic
ordering:
- Title (headline)
- Byline (author)
- Date
- Location
- Text
You want to entice the journalists to provide the geotags that go with the
story, so you can later repackage the content according to location (e.g. in
Doug's beloved layar or as hyperlocal site or something else). It's not only
about inserting maps (in fact, geotags do not need to be shown in a map at
all).
That was the logic. But we can play around with it (and btw, I all elements in
the right column will be collapsed to their respective when the article is
empty).
Perhaps info should be on the bottom indeed, with locations going up as I
suggested.
Let's continue the discussion.
Sava
On Friday, December 17, 2010 13:35:53 Vladimir Stefanovic wrote:
> Hi Claudia,
>
> thanks for your feedback. The position of the modules on the right is open
> for discussion, especially because the "drag and drop" feature will not be
> available at first. Any suggestion from the user point of view is more then
> welcome.
>
> The save bar would stick to the top of the browser if scrolled down,
> everything else would scroll down, as it does now. One solution would be to
> leave the breadcrumb bar also. This is definitely something that we should
> test on a html mock-up before making a final decision.
>
> fritz
>
>
> On 17 December 2010 06:34, Claudia Cruz
> <campsite-dev@lists.sourcefabric.org
>
> > wrote:
> > Hi Fritz,
> >
> > well, in general I like that the layout is very clean and intuitive, as
> > an editor I know exactly where i'm and how to get to other parts of my
> > publication as well as within the article.
> >
> > I would suggest, however, while we can make the right modules "drag and
> > drop", to consider the following order for those boxes:
> >
> > publish schedule
> > media
> > keywords
> > switches
> > info
> > location
> >
> > can we do that at his moment or was that not open to change???...my
> > suggestion comes from my times as editor...have them prioritize in order
> > of what is used more often.
> >
> > something else, am i not interpreting right this "forever on top" save
> > bar or does this modality hides/supersedes the two top menus??? because
> > if so, i wouldn't recomend it...editors/reporters are always bz/running
> > and as dumb as it sounds if they lose that anchor of "where i am" menu
> > while scrolling down it might get confusing...
> >
> >
> > -ccruz
Posts: 389Member, Administrator, Sourcefabric Team
Looking good.
I think the entire top menu & breadcrumbs should be sticky(not just the save
button part) and not move with the rest of the page. You may just be coming
in to an article to view it, you scroll down to look at something, and then
you want to navigate somewhere else. This can only happen if the top
control bar stays visible. This is one of the most annoying things about
Joomla...scroll down to check a box, then you have to scroll to the top of
the screen again to click an action. This is very simply solved with a
sticky top control bar.
> Hi Claudia,
>
> thanks for your feedback. The position of the modules on the right is open
> for discussion, especially because the "drag and drop" feature will not be
> available at first. Any suggestion from the user point of view is more then
> welcome.
>
> The save bar would stick to the top of the browser if scrolled down,
> everything else would scroll down, as it does now. One solution would be to
> leave the breadcrumb bar also. This is definitely something that we should
> test on a html mock-up before making a final decision.
>
> fritz
>
>
> On 17 December 2010 06:34, Claudia Cruz <
> campsite-dev@lists.sourcefabric.org
>
> > wrote:
>
> > Hi Fritz,
> >
> >
> > well, in general I like that the layout is very clean and intuitive, as
> an
> > editor I know exactly where i'm and how to get to other parts of my
> > publication as well as within the article.
> >
> > I would suggest, however, while we can make the right modules "drag and
> > drop", to consider the following order for those boxes:
> >
> > publish schedule
> > media
> > keywords
> > switches
> > info
> > location
> >
> > can we do that at his moment or was that not open to change???...my
> > suggestion comes from my times as editor...have them prioritize in order
> of
> > what is used more often.
> >
> > something else, am i not interpreting right this "forever on top" save
> bar
> > or does this modality hides/supersedes the two top menus??? because if
> so, i
> > wouldn't recomend it...editors/reporters are always bz/running and as
> dumb
> > as it sounds if they lose that anchor of "where i am" menu while
> scrolling
> > down it might get confusing...
> >
> >
> > -ccruz
> >
> >
>
>
>
> --
> Vladimir Stefanović
> *Interface Design and Usability, Sourcefabric*
> vladimir.stefanovic@sourcefabric.org
>
> Belgrade, Serbia
> +381 (0)64 156 2356
> Skype: fritzaman
>
> Subscribe to our Newsletter:
> www.sourcefabric.org/newsletter/
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
>
> Hi all,
> I very much agree with Doug that this is a huge improvement over what
> was there before.
>
> Unfortunately, I am not very happy with consistency on the page. My
> first few seconds impression was that the use of blue color as a
> contrast is not very clear. I was expecting that all blue text is
> clickable text with some function (article title, post a comment
> title, etc..). Also 'Edit' function does not follow consistency/
> repetition principle. It start's as blue text and one inch below is
> grey square button.
>
> Position of 'Article list' button is not placed very logically. It is
> a kind of navigation button which will take you away form the Article
> Edit page and should not brake any article filed from others (In this
> case article title).
>
> I also think the main box on the left with article fields are not
> following overall IA strategy on the page. Those basic and
> 'fundamental' fields do not need to be in one box but could be in a
> separate boxes. As a most important part of the Article Edit page it
> is still the same as it was before. Field titles like Deck, Lead/SMS,
> Body do not need to take so much space on the left. For example if you
> put it above the field (in a same style as other boxes) you will get
> more space for the text editor and everyone who is writing there or
> maintaining the publication will be very grateful for that (from
> personal experience :) ).
>
> As Sava, I also think the place for scheduled publishing is not ideal
> one but if it goes right it should not be "drag and drop". Maybe it
> could be placed on the right of the author and photographer and get
> the 'premium' place in the left bar. I would like to suggest, apart of
> blue color, to use a size or some other technics a bit as contrast to
> point importance of different features. Also, you may consider to
> colorize symbol eks (x) for delete in some warning color as red (at
> least on mouse over), especially because CS does not have recycle-bin/
> trash function.
>
> All in all, you have done very good work Fritz. Thanks.
>
> All the best,
> kiza
>
>
>
>
>
>
> On Dec 16, 2010, at 4:45 PM, Douglas Arellanes wrote:
>
> >
> > Hi Fritz,
> >
> > These are a _huge_ improvement over what was there before. I like
> > the overall consistency, especially with the look of the widgets on
> > the front page. Do you envision that, like the front page widgets,
> > users will be able to reorder the items in the second column?
> >
> > doug
> >
>
>
>
>
Posts: 113Member, Administrator, Sourcefabric Team
We have a good discussion going here. We'll implement as much as possible of
the consensus (or executive decision) at the end of this process, but don't
count on all of it making it into 3.5 (e.g. the Title field may still end up
living below with its cousins).
On to Kiza's concrete comments.
On Friday, December 17, 2010 18:19:32 Paul Baranowski wrote:
>>I was expecting that all blue text is
> > clickable text with some function (article title, post a comment
> > title, etc..). Also 'Edit' function does not follow consistency/
> > repetition principle. It start's as blue text and one inch below is
> > grey square button.
Good point re: consistency. Though the buttons don't necessarily have to
conform to the color coding.
> > Position of 'Article list' button is not placed very logically. It is
> > a kind of navigation button which will take you away form the Article
> > Edit page and should not brake any article filed from others (In this
> > case article title).
Yes, this is unfortunate. It had crossed my mind as well. Perhaps we should
consider eliminating this navigation as it is redundant... The new breadcrumbs
should be more than an adequate substitution for <--Article list... add new
article can be accessed from the Actions menu... Though it wouldn't be bad to
have a persistent Add new shortcut (not only article, but any type of
content). So if anyone has any bright ideas re: these two buttons, please come
forth.
> > I also think the main box on the left with article fields are not
> > following overall IA strategy on the page. Those basic and
> > 'fundamental' fields do not need to be in one box but could be in a
> > separate boxes.
Do you mean author boxes and the dates?
> > As a most important part of the Article Edit page it
> > is still the same as it was before. Field titles like Deck, Lead/SMS,
> > Body do not need to take so much space on the left. For example if you
> > put it above the field (in a same style as other boxes) you will get
> > more space for the text editor and everyone who is writing there or
> > maintaining the publication will be very grateful for that (from
> > personal experience :) ).
We've discussed putting the labels up. Fritz will give it a try. It'd be even
better if we could control the size of the fields edited by Tiny (doubt that
we can squeeze it in 3.5, but in 3.5.1, why not). Eliminating the empty space
on the left would pave the way for an ingest pane on the left in the future...
So we'll definitely explore it.
> > As Sava, I also think the place for scheduled publishing is not ideal
> > one but if it goes right it should not be "drag and drop". Maybe it
> > could be placed on the right of the author and photographer and get
> > the 'premium' place in the left bar.
I think it should stay on the right, and it shouldn't be drag and droppable.
It doesn't take too much space when it's collapsed. The same goes for the
Actions row (now, should this not be visible at all times as well?)
> > I would like to suggest, apart of
> > blue color, to use a size or some other technics a bit as contrast to
> > point importance of different features. Also, you may consider to
> > colorize symbol eks (x) for delete in some warning color as red (at
> > least on mouse over), especially because CS does not have recycle-bin/
> > trash function.
Not sure we need to make a Christmas tree out of it either. CS may not have a
trash function, but Firefox, for example, gives you a nice ctrl+z undo
function for text-type fields, even after you save (tested with a dev version
of 3.5). So the x is not capable of inflicting some irreparable damage.
All the best,
Sava
> > On Dec 16, 2010, at 4:45 PM, Douglas Arellanes wrote:
> > > Hi Fritz,
> > >
> > > These are a _huge_ improvement over what was there before. I like
> > > the overall consistency, especially with the look of the widgets on
> > > the front page. Do you envision that, like the front page widgets,
> > > users will be able to reorder the items in the second column?
> > >
> > > doug
>
> To participate in the discussion, go here:
> http://forum.sourcefabric.org/index.php?t=rview&frm_id=1 1
Savo,
I was referring to blue eks's on widget bar. for example if you delete
an image ctrl/cmd+z will not help much. Red x is already seen in issue
list on present design and it does not look like a Christmas tree to
me but quite smart. It is OK to warn user when he takes some radical
action as deleting is. Also, i have seen something similar on other
CMS's too and I like it :) .
On Dec 17, 2010, at 7:04 PM, Sava Tatić wrote:
>
>
> > > I would like to suggest, apart of
> > > blue color, to use a size or some other technics a bit as
> contrast to
> > > point importance of different features. Also, you may consider to
> > > colorize symbol eks (x) for delete in some warning color as red
> (at
> > > least on mouse over), especially because CS does not have
> recycle-bin/
> > > trash function.
>
>
> Not sure we need to make a Christmas tree out of it either. CS may
> not have a
> trash function, but Firefox, for example, gives you a nice ctrl+z undo
> function for text-type fields, even after you save (tested with a
> dev version
> of 3.5). So the x is not capable of inflicting some irreparable
> damage.
>
> All the best,
>
> Sava
>
>
> > > On Dec 16, 2010, at 4:45 PM, Douglas Arellanes wrote:
> > > > Hi Fritz,
> > > >
> > > > These are a _huge_ improvement over what was there before. I
> like
> > > > the overall consistency, especially with the look of the
> widgets on
> > > > the front page. Do you envision that, like the front page
> widgets,
> > > > users will be able to reorder the items in the second column?
> > > >
> > > > doug
> >
> > To participate in the discussion, go here:
> > http://forum.sourcefabric.org/index.php?t=rview&frm_id=1 1
>
> --
> Sava Tatić
> Managing Director, Sourcefabric o.p.s.
> sava.tatic@sourcefabric.org
>
> Salvátorská 10
> 110 00 Praha 1, Czech Republic
> +420222362540
> +420602653104 (mobile)
> Skype: tictactatic
>
> Subscribe to our Newsletter:
> www.sourcefabric.org/newsletter/
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
Posts: 113Member, Administrator, Sourcefabric Team
On Friday, December 17, 2010 19:59:14 zoran.zivkovic wrote:
> Savo,
> I was referring to blue eks's on widget bar. for example if you delete
> an image ctrl/cmd+z will not help much. Red x is already seen in issue
> list on present design and it does not look like a Christmas tree to
> me but quite smart. It is OK to warn user when he takes some radical
> action as deleting is. Also, i have seen something similar on other
> CMS's too and I like it :) .
Ah sorry, I thought you were talking about text-field values.
But in any case, image, file, topic... none of this is destructive in Campsite,
i.e. you don't delete them from a the archive. You simply re-atttach. Deleting
an issue on the other hand is a big issue. So somehow we've had it right. :)
I don't mind warning people about potetntial consequences, but perhaps there
should be some gradation in terms of danger (again, not a priority for 3.5.).
Can you attach some screenshots from the examples you like? (just the detail).
It is not about what we can do to make it as it was but more a way of
communication.
There is no gradation... you did delete something or you didn't. It is
just one minute work in CSS and it is optional... if you like it make
it.. if you don't leave it blue... :) Not a big deal.
>
> On Friday, December 17, 2010 19:59:14 zoran.zivkovic wrote:
> > Savo,
> > I was referring to blue eks's on widget bar. for example if you
> delete
> > an image ctrl/cmd+z will not help much. Red x is already seen in
> issue
> > list on present design and it does not look like a Christmas tree to
> > me but quite smart. It is OK to warn user when he takes some radical
> > action as deleting is. Also, i have seen something similar on other
> > CMS's too and I like it :) .
>
> Ah sorry, I thought you were talking about text-field values.
>
> But in any case, image, file, topic... none of this is destructive
> in Campsite,
> i.e. you don't delete them from a the archive. You simply re-
> atttach. Deleting
> an issue on the other hand is a big issue. So somehow we've had it
> right. :)
>
> I don't mind warning people about potetntial consequences, but
> perhaps there
> should be some gradation in terms of danger (again, not a priority
> for 3.5.).
>
> Can you attach some screenshots from the examples you like? (just
> the detail).
>
> All the best,
>
> Sava
>
>
>