Design work now on github

[Felipe]

Hi All,

We've just moved our design files to github so everyone can keep track
of how we're progressing on them
ATTENTION: its all work in progress

Check it out:
https://github.com/silverstripe/silverstripe-design

Design concepts
https://github.com/silverstripe/silverstripe-design/tree/master/Design

I'm happy to hear your thoughts but keep in mind this is not an
official announcement for the final design
and a lot can change till we get there...

Cheers
Felipe

[Hamish Campbell]

It looks awesome Felipe!

Hamish

On Feb 22, 5:51 pm, Felipe <felipeskro...@gmail.com> wrote:
> Hi All,
>
> We've just moved our design files to github so everyone can keep track
> of how we're progressing on them
> ATTENTION: its all work in progress
>
> Check it out:https://github.com/silverstripe/silverstripe-design
>

> Design conceptshttps://github.com/silverstripe/silverstripe-design/tree/master/Design

[jaytay]

Awesome, thanks Felipe. Huge improvements on readability and
typography.

Couple of quick thoughts:
UI wise I see a big emphasis on the Workflow in one of the Page
views. Workflow hasn't been a big need for our clients but maybe this
is a common request? I could see this being very useful in bigger
sites.

I like that I am seeing the nested tabs in the edit screen are gone.
I hope this carries through to the final redesign.

Edit Screen: "Page Settings" is a much better name than "Behaviour"

Edit Screen: Thank you for getting rid of "To-dos" and "Google
Sitemap" tabs and all that extraneous crap that our clients rarely use
or know how to use. Though I would still like to see a reduction in
the number of tabs at the top for a couple of reasons. 1) sometimes
new tabs need to be created to manage secondary content such as
callouts or testimonials (usually using Uncle Cheese's DOM) and this
can quickly eat up available space in a horizontal tabbed navigation.
2) To many choices to make it hard for the user to qualify where the
content/data is.

This is a great start and can't wait to see more.

On Feb 21, 11:51 pm, Felipe <felipeskro...@gmail.com> wrote:
> Hi All,
>
> We've just moved our design files to github so everyone can keep track
> of how we're progressing on them
> ATTENTION: its all work in progress
>
> Check it out:https://github.com/silverstripe/silverstripe-design
>

> Design conceptshttps://github.com/silverstripe/silverstripe-design/tree/master/Design

[Dan Rye]

I'm really liking this so far.  I imagine the delete is the way it is so that it isn't prominent.  But for some reason I look at it and wish it was a button also.  I'm sure there is a good UX reason for it to not be though.

I really like the collapsible nature of the panels, the full screen list and tree views.  Very nice improvements. 

Thank you for sharing, very exciting stuff.

-Dan

On Mon, Feb 21, 2011 at 11:58 PM, Felipe <felipe...@gmail.com> wrote:

Hi All,

We've just moved our design files to github so everyone can keep track
of how we're progressing on them
ATTENTION: its all work in progress

Check it out:
https://github.com/silverstripe/silverstripe-design

Design concepts
https://github.com/silverstripe/silverstripe-design/tree/master/Design

I'm happy to hear your thoughts but keep in mind this is not an
official announcement for the final design
and a lot can change till we get there...

Cheers
Felipe

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Uncle Cheese]

This is awesome. Can I have it now?

I would add a little uploader and a browse button in the bottom left
corner, so that asset management is persistent throughout the CMS.
It's a pain to go to AssetAmin just to upload one file. I would like
to see assets more globally integrated.

Felipe, you rock. I'm psyched that SilverStripe found you!

-A

[Martijn Van Nieuwenhoven]

I really love this!
If this listviews are the new TableFields.... awesome..
Ultimate blueprints for ModelAdmin ;) Do we get subnavs for the leftbar as well?

[Hamish Campbell]

On Feb 23, 6:07 am, Uncle Cheese <aaroncarl...@gmail.com> wrote:
> ...so that asset management is persistent throughout the CMS.

+1

[Michael Andrewartha]

Hey Felipe,

I especially like using the icons only (in ss3-ui_Pages- list view.jpg) and would assume the full title would appear when you hover on the house icon (in this instance)? One advantage for this design would be to save on space for users that are still using SilverStripe in low screen resolutions or on ipads etc.

At the moment you can only edit one page at a time with the site tree, however in the design it looks like you can select multiple pages and then click "edit content", how would you see that working? Would each content page appear one by one and then once you choose a button it would move to the next page selected?

Also if I was looking at a page (example on ss3-ui_Edit content.jpg), could there be buttons to move to the next/prev page in the section and also go back to the tree/list view (kinda like the prev/next buttons under the Pages list view table, just for easy navigation when you can't see the tree/table view).

Also around using tabs (ss3-ui_Edit content.jpg), I know it is a sore point with the current design. A few sites I've been involved in building use far too many tabs, thus breaking the look of the edit content area. Any ideas about how to best resolve this issue in future?

Can anyone think about other areas where you know where the current design falls short and can be improved in ss3, would be good to hear your ideas.

Cheers for the designs Felipe, the new ss3 design refresh is gonna rock! : )

Mike.

On Wed, Feb 23, 2011 at 10:13 AM, Sam Minnée <s...@silverstripe.com> wrote:

> UI wise I see a big emphasis on the Workflow in one of the Page
> views.  Workflow hasn't been a big need for our clients but maybe this
> is a common request?  I could see this being very useful in bigger
> sites.

Workflow is a module; the reason they've been included in the mock-up is to show how the design can handle a large number of custom actions.  As much as designing a specific UI we're also designing a framework that other modules will plug into.

The specific list of buttons was derived from the existing cmsworkflow module, although Marcus et al have been working on an advancedworkflow module that looks quite promising.

At this stage I wouldn't worry too much about the workflow related stuff; we're focusing on the core product first.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--

Michael Andrewartha | Developer

SilverStripe
http://silverstripe.com

Phone: +64 4 978 7330 #53

[Marcus Nyeholt]

Couple of quick thoughts:
UI wise I see a big emphasis on the Workflow in one of the Page
views.  Workflow hasn't been a big need for our clients but maybe this
is a common request?  I could see this being very useful in bigger
sites.

As Sam mentioned, we've developed an advanced workflow module that allows specification of the workflow process within the CMS, so that business users can actually define what goes it. It's still relatively immature, but slowly improving. Ultimately the goal with the module is so that it's not 'just' for an approval process (which it is largely designed for at the moment) but for any arbitrary step by step process that users need to follow and be assigned to steps along the way. You can give it a go at https://github.com/silverstripe-australia/advancedworkflow if you're interested

Marcus

[Sam Minnée]

> UI wise I see a big emphasis on the Workflow in one of the Page
> views. Workflow hasn't been a big need for our clients but maybe this
> is a common request? I could see this being very useful in bigger
> sites.

Workflow is a module; the reason they've been included in the mock-up is to show how the design can handle a large number of custom actions. As much as designing a specific UI we're also designing a framework that other modules will plug into.

[Sam Minnée]

Yeah, Felipe hasn't started on the asset management redesign yet. Or security/permissions.

[Ingo Schommer]

First of all, I'm very very excited about the new designs :)

Question: I assume the "preview" button would not save a new version to draft, right? (which is why we have a separate "save to draft" button)

Apart from the fact that this feature doesn't exist in SilverStripe at the moment, I think would be difficult from a UX perspective:

In addition to "draft" and "live" we're now adding a third "view mode" (currently authors use draft=preview) - can we communicate these states effectively?

@devs: How would you see the datamodel working for this? A temporary version that gets flagged as a preview? Or using a new ORM feature

which can get data from a different table?

[Dan Rye]

@Ingo I took preview to be like the current draft site link in the footer:

Page view: CMS Draft Site Published Site

However I questioned how you would view published.  

It would be nice if you could toggle between the three views: CMS,draft,live.  

--

[Felipe Skroski]

Hi All i've just gon a nice case of extreme use of tabs here isr the x-ray:

⁃ Content[tab]

- Main[tab]

⁃ Page Name [text field]

⁃ Navigation label [text field]

⁃ Content [tiny mce]

- Metadata[tab]

⁃ Url [text field]

⁃ Title [text field]

⁃ Description [text area]

⁃ Keywords [text area]

⁃ Custom metatags [text area]

- Right column[tab]

⁃ Html widget [tiny mce]

- Related video[tab]

⁃ related video [combobox]

- Flickr photos[tab]

⁃ Page name [datagrid]

⁃ Behaviour [tab]

- Page type [combobox]

- Show in menus [checkbox]

- Show in search [checkbox]

- Allow comments on this page [checkbox]

- Domain(s) [textfield]

- Hide from sitemap [checkbox]

- To-do [tab]

- todo [text area]

- Reports [tab]

- Backlinks [tab] 

- link to this page [datagrid]

- Access [tab]

- who can view this ? [checkbox * 3]

- who can edit this ? [checkbox * 2]

- Media [tab]

- Video embed code [text area]

- Video caption [textfield]

- Photo for the blog [file uploader]

- Caption [textfield]

- Sponsor [tab]

- Link [Textfield]

- File [Textfield]

- Is this a flash movie [Textfield]

- flash height [Textfield]

- flash width [Textfield]

- Tips [tab]

- xml file [File uploader]

- Home [tab]

⁃ Banner [tab]

⁃ title

⁃ link

⁃ files [datagrid]

⁃ Time to [tab]

⁃ [datagrid]

⁃ Most popular [tab]

⁃ [datagrid]

⁃ Kitchen table [tab]

⁃ [datagrid]

⁃ Blog [tab]

⁃ Blog image [file uploader]

- Blog caption [text field]

- Link [text field]

- turn off [checkbox]

- title [txt box]

- Content [tiny mce]

⁃ Shop [tab]

- Link [text field]

- image [file uploader]

⁃ Guys we love [tab]

- Caption [textbox]

- Link to page [textbox]

- Open in a new window [checkbox]

- Image [File uploader]

- Title image [File uploader]

- More image [File uploader]

- Quote [tiny mce]

⁃ Kiva [tab]

- Caption [textbox]

- Link to page [textbox]

- Open in a new window [checkbox]

- Image [File uploader]

- Title image [File uploader]

- More image [File uploader]

- Content [tiny mce]

⁃ Partners [tab]

- Top left title [textbox]

- Top left link [textbox]

- Top left Content [tiny mce]

- Top left image [File uploader]

- Top right title [textbox]

- Top right link [textbox]

- Top right Content [tiny mce]

- Top right image [File uploader]

- Bottom left title [textbox]

- Bottom left link [textbox]

- Bottom left Content [tiny mce]

- Bottom left image [File uploader]

- Bottom right title [textbox]

- Bottom right link [textbox]

- Bottom right Content [tiny mce]

- Bottom right image [File uploader]

⁃ What we do [tab]

- Image [File uploader] * 10

⁃ Social networks [tab]

- Link [Textfield] * 10

- Sponsors [tab]

- Sponsor title [textbox]

- Sponsor Link [textbox]

- Sponsor logo [File uploader]

- open in a new window [checkbox]

- Sponsor title [textbox]

- Sponsor Link [textbox]

- Sponsor logo [File uploader]

- open in a new window [checkbox]

- Sponsor title [textbox]

- Sponsor Link [textbox]

- Sponsor logo [File uploader]

- open in a new window [checkbox]

- Sponsor title [textbox]

- Sponsor Link [textbox]

- Sponsor logo [File uploader]

- open in a new window [checkbox]

 

and here is an image of the beast: 

https://github.com/silverstripe/silverstripe-design/blob/master/Assets/Tabs-edge-cases/tabs.png

Let me know if you have more extreme tab uses than that. 

Felipe

On Wed, Feb 23, 2011 at 4:38 PM, Felipe Skroski <felipe...@gmail.com> wrote:

@ingo Preview would be only to refresh the website [far right panel on Design/ss3-ui_Edit content- hd resolution.jpg ] without saving any content just to check how the content looks like on the actual website - that assuming you think it's possible of course...

[Felipe]

@all: Thanks all for the quality feedback (positive or negative), I
think you really got the point and all the comments are really useful
to enhance those concepts on the next iterations.
Regarding the positive feedback to me, all the design team members
are working on it so Will, David and Paul all the feedback here is for
your work too :)

@jaytay: I'm with you we need to give users a sense of hierarchy (more
x less important tasks) as Sam said workflow is there to simulate an
edge case. Regarding tabs my understanding is
that the system should be customizable enough for you to display or
hide the options you judge necessary for the project, Sam correct me
if I'm wrong

@dan rye: there is a reason for delete to be less prominent: 1) people
create and update much more than delete pages 2) after delete it's
gone (I need to double check that with devs though) as if you create
you can simply delete if it was an accident.

@Uncle Cheese: Totally agree with you the action to include assets
should be present on the edit content action, we're planning to
address the asset management and how it cascades through the system in
the next iteration so stay tunned.

@Martjin: yes we have a concept with subnav on the left navigation I
should say thou that we'll have a limit of one level (so no 7 level
craziness there) and we are pushing as far as we can to not using a
second level at all- short reason: more information = less attention =
bad user experience

@Mike:
Q1) no there is no way you can edit content of multiple pages have a
look at ss3-ui_Pages- tree view-05.jpg no content edit action when you
have 2 or more items there.
Q2) I like the idea but first I want to see how the other elements
such as asset management are going to affect that - I prefer to keep
only the critical actions and avoid clutter ...
Q3) The tabs issue is an information architecture issue, the way to
reduce the number of tabs is by having more content per tab, the
biggest mistake I see now is people creating tabs to add 1 txt
field...
around 80% of the tasks on the cms is about updating and creating
content the rest is minor. So instead of simply add new tabs we should
add elements /actions to their context, so you created a featured
image on that page?
add that under content, you added a new cool feature ? add that on
page settings ? maybe we should put (metadata and access under page
settings) I would open exceptions for workflow and model admin that
require more interaction...
so on an edge case you'll end up with four tabs :

- Content
- title
- content
- [your custumized fields related to content]
- [asset management]

- Page settings
- URL
- Page type
- Page location
- Visibility
- Allow comments
- Author
- Date
- Metadata
- Access
- [all the customization you create related to settings]

- Workflow
- review
- [all the workflow stuff]

- Model admin {needs a better title}
- [model admin stuff]

- [Custom tab] - only if the thing you created is *very large* and as
important as the content..

What do you think?

@All: I'm looking for edge cases now so if you have an interface
totally bloated with options send me screenshots :)

Cheers
Felipe

[Felipe Skroski]

@ingo Preview would be only to refresh the website [far right panel on Design/ss3-ui_Edit content- hd resolution.jpg ] without saving any content just to check how the content looks like on the actual website - that assuming you think it's possible of course...

On Wed, Feb 23, 2011 at 4:30 PM, Dan Rye <dan...@gmail.com> wrote:

[DesignCity]

Looks fantastic, Felipe. I have them pinned up on a chalkboard to mull
them all over! Looking forward to following up with some feedback
later down the track :)

Michael

On Feb 22, 12:51 pm, Felipe <felipeskro...@gmail.com> wrote:
> Hi All,
>
> We've just moved our design files to github so everyone can keep track
> of how we're progressing on them
> ATTENTION: its all work in progress
>
> Check it out:https://github.com/silverstripe/silverstripe-design
>

> Design conceptshttps://github.com/silverstripe/silverstripe-design/tree/master/Design

[Nicolaas Thiemen Francken - Sunny Side Up]

fantastic - cant wait.

[Michael Andrewartha]

 

2) after delete it's gone (I need to double check that with devs though) as if you create
you can simply delete if it was an accident.

Not quite... just use the "All pages including deleted" option in the tree Show dropdown to find your deleted pages and revert your pages from there. No page is technically deleted as there is always a copy of it in the page version history. Its great to show clients this option as I get the "oh no I've deleted a page, what do i do..." question a lot : )

 

 Q3) The tabs issue is an information architecture issue, the way to
reduce the number of tabs is by having more content per tab, the
biggest mistake I see now is people creating tabs to add 1 txt
field...

Another thing to think about here is better ways to structure fields inside tabs. Tabs only go so far with structuring fields and the less tabs the better, however if fields aren't structured well inside the tab then its best if you just create more tabs as they are more obvious when you click on a page : )

In my experience with adding too many items inside one tab, users don't automatically think of scrolling down to find fields so they have a quick look in each tab and if it isn't obvious to them, they will get frustrated and ask where they are supposed to edit a section of the website rather then spending time looking for it themselves.

 

@All: I'm looking for edge cases now so if you have an interface
totally bloated with options send me screenshots :)

Haha looks like that screenshot has an extreme case of tabulitis :D (sorry for the bad pun)

 

Cheers
Felipe

On Feb 23, 10:13 am, Sam Minnée <s...@silverstripe.com> wrote:
> > UI wise I see a big emphasis on the Workflow in one of the Page
> > views.  Workflow hasn't been a big need for our clients but maybe this
> > is a common request?  I could see this being very useful in bigger
> > sites.
>
> Workflow is a module; the reason they've been included in the mock-up is to show how the design can handle a large number of custom actions.  As much as designing a specific UI we're also designing a framework that other modules will plug into.
>
> The specific list of buttons was derived from the existing cmsworkflow module, although Marcus et al have been working on an advancedworkflow module that looks quite promising.
>
> At this stage I wouldn't worry too much about the workflow related stuff; we're focusing on the core product first.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--

[Felipe Skroski]

On Wed, Feb 23, 2011 at 9:13 PM, Michael Andrewartha <mic...@silverstripe.com> wrote:

 

2) after delete it's gone (I need to double check that with devs though) as if you create
you can simply delete if it was an accident.

Not quite... just use the "All pages including deleted" option in the tree Show dropdown to find your deleted pages and revert your pages from there. No page is technically deleted as there is always a copy of it in the page version history. Its great to show clients this option as I get the "oh no I've deleted a page, what do i do..." question a lot : )

 

well if people request for support is because they are completely lost, this is not good. If they can recover the file we need to rename the action, it needs to be called 'move to trash' instead of 'delete' so there won't be ohhs and ahhs when you do the action, people will simply think "ok now where is the trash?" and that should be obvious either so users will be happier and you save your time not answering that anymore :)

 

 

 Q3) The tabs issue is an information architecture issue, the way to
reduce the number of tabs is by having more content per tab, the
biggest mistake I see now is people creating tabs to add 1 txt
field...

Another thing to think about here is better ways to structure fields inside tabs. Tabs only go so far with structuring fields and the less tabs the better, however if fields aren't structured well inside the tab then its best if you just create more tabs as they are more obvious when you click on a page : )

In my experience with adding too many items inside one tab, users don't automatically think of scrolling down to find fields so they have a quick look in each tab and if it isn't obvious to them, they will get frustrated and ask where they are supposed to edit a section of the website rather then spending time looking for it themselves.

Structuring fields is something every developer should carefully think about, we can provide good defaults for common elements, standards, guidelines, ui components, but given the flexibility of this new version you can build whatever you want on top of it and that is devs responsibility to make it usable at least.   

In my experience people scroll a lot. 1) scrolling is a no brainer you can use the mouse wheel of a finger swipe much easier than reading, interpreting, pointing the mouse on the right place and clicking. 2) get the 3 main websites of the planet google, facebook and twittter, all of them people need to scroll and we're talking about probably 90% of internet users here if not more. 3) read these articles: http://iampaddy.com/lifebelow600/ and try this site http://www.thereisnopagefold.com/. If after that you still think people don't scroll please give me good sources to support that.

Although there is one thing I agree with you, we need to make the page look scrollable which is not the case today.

 

 

@All: I'm looking for edge cases now so if you have an interface
totally bloated with options send me screenshots :)

Haha looks like that screenshot has an extreme case of tabulitis :D (sorry for the bad pun)

sure that is a decent UI challenge but we're on the right track to get that sorted.

[Uncle Cheese]

I'd like to strongly discourage the use of nested tabsets. They look
awful, they're a poor use of space, and users can't figure them out.

Consider a single set of horizontal tabs and when there are a large
number of fields on a given tab, use a nested set of vertical tabs, or
headings that blind down a set of fields. You might call it an
"accordion" in the jQuery world. Something like that would be much
more practical than continuing the nested tab adventure.

On Feb 23, 4:57 am, Felipe Skroski <felipeskro...@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 9:13 PM, Michael Andrewartha <
>

> here if not more. 3) read these articles:http://iampaddy.com/lifebelow600/andtry this sitehttp://www.thereisnopagefold.com/. If after that you still think people

[Michael Andrewartha]

On Thu, Feb 24, 2011 at 4:26 AM, Uncle Cheese <aaronc...@gmail.com> wrote:

I'd like to strongly discourage the use of nested tabsets. They look
awful, they're a poor use of space, and users can't figure them out.

Consider a single set of horizontal tabs and when there are a large
number of fields on a given tab, use a nested set of vertical tabs, or
headings that blind down a set of fields. You might call it an
"accordion" in the jQuery world. Something like that would be much
more practical than continuing the nested tab adventure.

Hi Uncle Cheese, yes having an accordion style tab list down the page would be a great idea, they would reduce space and hopefully go some way to solving the issues I was having. What do you think Felipe?

[Hamish Campbell]

On Feb 23, 10:57 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:
> > In my experience with adding too many items inside one tab, users don't
> > automatically think of scrolling down to find fields so they have a quick
> > look in each tab and if it isn't obvious to them, they will get frustrated
> > and ask where they are supposed to edit a section of the website rather then
> > spending time looking for it themselves.
>

> ...

>
> In my experience people scroll a lot. 1) scrolling is a no brainer you can
> use the mouse wheel of a finger swipe much easier than reading,
> interpreting, pointing the mouse on the right place and clicking.

I've seen this problem as well with nested tabs. The problem is that
people get used to the scroll-less nature of the CMS in general (and I
think we've all got into the habit of trying to keep each tab to one
page), so when form extends past the bottom of the screen then it is
easier for a user to click through the different tabs than to scroll,
click a tab, scroll, click a tab.

I think the new design as it stands makes it much clearer that the
page extends, rather than just the nested content - which is where
there is a difference between the sites you mentioned and the issue
we're seeing in the CMS.

Hamish Campbell

[Sigurd Magnusson]

Supporting the idea that nested tabs are a hack, but open to Felipe and others to suggest improvements.

The idea to make scrolling feel natural (ie. better affordance) or accordians seem interesting in theory. Having something to see (and later interact with) will be a good way to test the theories.

:)

Cheers

Sig

--

[Brice Burgess]

On 2/23/2011 9:26 AM, Uncle Cheese wrote:
> I'd like to strongly discourage the use of nested tabsets. They look
> awful, they're a poor use of space, and users can't figure them out.
>
> Consider a single set of horizontal tabs and when there are a large
> number of fields on a given tab, use a nested set of vertical tabs, or
> headings that blind down a set of fields. You might call it an
> "accordion" in the jQuery world. Something like that would be much
> more practical than continuing the nested tab adventure.

I personally see Nested tabs as preferable, as you retain the same width
in the layout below them. If you introduce an accordion in a sidebar for
secondary items, it changes the layout (and width of the main pane).
That said; vertical layouts are preferable when you have many items
because they use less precious [horizontal] space -- so if you're going
to use them; they ought to be persistent.

~ Brice

[Nivanka Fonseka]

Hey, 

this is really awesome.

love the way you have made it look more calm, it will be super easy for new users of SilverStripe 

to find out what they need. 

also love the way you have done the page structure, I have done sites which has more than 3, 000 pages, and this

new list view will make it super easy to find out the page rather than a tree. Would like to know what are the plans for search text field of

page view?

Multi Selection will be a more meaningful term rather than batch actions

cant wait to see the asset admin, security admin and the rest, mostly the model admin

great work Felipe

- nivanka

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--
Nivanka Fonseka
Senior Software Engineer

Skype: nivanka.fonseka
Twitter: @nivankafonseka

[Uncle Cheese]

Web interfaces, by their nature, discourage horizontal growth and
invite vertical growth. Web pages scroll infinitely, so I think it
behooves us to use that space as much as possible. One of my biggest
gripes with the SS UI right now is that is condemns scrolling, and
promotes the idea that everything should be sized to fit vertically,
when in fact, scrolling is the most intuitive behaviour on the web,
and it's completely natural for an application to extend beyond the
viewport.

What isn't natural, or expected, for that matter, is forcing a fixed
height with a string of Javascript hacks every time the window size
changes. That's gotta go!

[Sigurd Magnusson]

Aaron. Good points, I agree. To expand, I note one aspect of the current UI that discourages an expectation of scrolling is the existence of a footer/status bar; the new interface in SS 3 has no footer, and contributes to an idea that you can scroll. It's not the only factor, for sure, but your post made me think about how the footer plays its part here.

[Ingo Schommer]

Agreed as well - part of the reason the CMS is so hard to customize

is the fact that its trying to be an application (with pure CSS,

lots of JS resize hacks, and little abstraction).

The more we can make the CMS behave like a scrollable website

(while ensuring that enough info and actions are available unscrolled),

the more we can enable web developers to work in this framework.

One of the most complex aspects of the jQuery rewrite UI (in master)

is the jQuery.layout plugin necessary to make all the panels behave.

Ingo

On 25/02/2011, at 11:46 AM, Sigurd Magnusson wrote:

Aaron. Good points, I agree. To expand, I note one aspect of the current UI that discourages an expectation of scrolling is the existence of a footer/status bar; the new interface in SS 3 has no footer, and contributes to an idea that you can scroll. It's not the only factor, for sure, but your post made me think about how the footer plays its part here.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23

[Michael Andrewartha]

More thoughts/ideas about the new designs and ss3.0.

Widgets: At the moment, some work is needed in order to add widgets into 2.4 which shouldn't really be the case as widgets are a big part of the CMS, however at the moment they just seem to be tacked onto the end and get lost with everything else. Is the idea for 3.0 to better integrate widgets into the CMS and how should this look like?

Inline help: Not sure if this had been mentioned on the dev group so I thought I'd mention it. 

It would be great to have the ability to add bite sized help links/buttons to different parts of the CMS which then allow developers to give the client more information about the section/tab/field they are looking at. This could be as simple as just a direct link to the information at http://userhelp.silverstripe.com/ or a pop up box explaining in short what to do here. Again I'm not sure how this would look like in the CMS but it would be much better then sending users to http://userhelp.silverstripe.com/ and then still expect them to find what help they need on their own?

BTW User help needs a search area (would be awesome if it looked similar to http://www.google.com/support/pages/?hl=en but that is another discussion).

and on the topic of search... 

As the focus for ss3.0 is heading away from just using the site tree, it would be good if the Site Tree search also looked for more then just pages in the site tree (e.g. DataObjects, members etc). It would be another way to help users find what they want really quickly!

Thoughts?

Mike.

--

Michael Andrewartha | Developer

SilverStripe
http://silverstripe.com

Phone: +64 4 978 7330 #53

[Hamish Friedlander]

What isn't natural, or expected, for that matter, is forcing a fixed
height with a string of Javascript hacks every time the window size
changes. That's gotta go!

 

While I agree that the current system is excessively javascript-heavy, there's nothing wrong with fixed-height systems if they're implemented right, and I disagree that we should discard it.

I'm not saying tab nightmares are better for lots of data than scrolling, but if you're trying to fit that much data on a single page you're doing something wrong anyway, and I would hate to see the default experience crippled to compensate for the worst case.

In particular, if you look at Design/ss3-ui_content-hd-resolution.jpg you can see the concept if is for the admin panel to float over the website (if your screen is big enough). Early prototypes show this is a _massive_ win for finding & editing content (the most common operation) for very little programming effort.

But if we make the admin panel scrollable, that'll mean a scroll bar in the middle of the screen. And in my opinion, multiple scrollbars is way worse than fixed height layout.

Hamish Friedlander

[Hamish Friedlander]

 

Widgets: At the moment, some work is needed in order to add widgets into 2.4 which shouldn't really be the case as widgets are a big part of the CMS, however at the moment they just seem to be tacked onto the end and get lost with everything else. Is the idea for 3.0 to better integrate widgets into the CMS and how should this look like?

The problem is that take 100 people, and you'll get 150 ideas about how widgets should work. Some people just want small tweaks to the current system, some people want template-snippet injection, some people want full GUI layout / template edit tools. 

While it'd be cool to have a new widget system in 3, I can just see it causing massive delays while we try to hash out the details.

There's nothing API breaking about adding a widget system, so I'd rather see us add APIs that make writing widget-style modules easy (including things like the thread on injecting widgets into tinymce). Then let people write modules for how they think widgets should work, & crown the winner victorious.

 

Inline help: Not sure if this had been mentioned on the dev group so I thought I'd mention it. 

It would be great to have the ability to add bite sized help links/buttons to different parts of the CMS which then allow developers to give the client more information about the section/tab/field they are looking at. This could be as simple as just a direct link to the information at http://userhelp.silverstripe.com/ or a pop up box explaining in short what to do here. Again I'm not sure how this would look like in the CMS but it would be much better then sending users to http://userhelp.silverstripe.com/ and then still expect them to find what help they need on their own?

Agree. Even something like context sensitive help (if tinymce is in focus, send them to the userhelp page on tinymce) would be better than what we've got now. 

As the focus for ss3.0 is heading away from just using the site tree, it would be good if the Site Tree search also looked for more then just pages in the site tree (e.g. DataObjects, members etc). It would be another way to help users find what they want really quickly!

Hmm. I like the idea of a global search, but the sitetree already is too complicated for some users, and it's not immediately obvious where extra elements would go.

You could include them in the list view though. Or maybe a separate major tab (along with content, pages, security, etc - is there a better term for these?)  for global search. Or make the search on the top right present on every major tab and make it work like OS X spotlight.

Hamish Friedlander

[Uncle Cheese]

Well the scrollbars have to go somewhere, even in a fixed height
layout. Look at the current UI.. the tabsets just have an
overflow:auto on them creating a scrollable div. There's nothing sexy
about that, either. I agree, scrollbars are ugly, especially for
Windows users, but unless you can throttle the amount of content
appearing on the page, you're going to have to deal with them at some
point, whether they're on the window or on a block element.

There's nothing wrong with using fixed positioning to anchor important
actions (e.g. "save and publish") to be persistent in the viewport.
The best part is, you don't need 60k of resize events to do that.



On Feb 25, 2:22 pm, Hamish Friedlander <ham...@silverstripe.com>
wrote:

[Hamish Friedlander]

On 26 February 2011 08:38, Uncle Cheese <aaronc...@gmail.com> wrote:

Well the scrollbars have to go somewhere, even in a fixed height
layout. Look at the current UI.. the tabsets just have an
overflow:auto on them creating a scrollable div. There's nothing sexy
about that, either. I agree, scrollbars are ugly, especially for
Windows users, but unless you can throttle the amount of content
appearing on the page, you're going to have to deal with them at some
point, whether they're on the window or on a block element.

But with a reduced tabset, I think the scrollbar on the tab div will feel more "natural" than on the main edit panel. I'm not saying that's definitely the way to do it, but I see at least as many issues with intrinsic height as with managed height systems

 

There's nothing wrong with using fixed positioning to anchor important
actions (e.g. "save and publish") to be persistent in the viewport.
The best part is, you don't need 60k of resize events to do that.

I don't think technical implementation details should play a part in UX decisions. Especially since there are better ways of doing things now (see: css3 flexible box layouts) 

We're still going to have to have height management in an intrinsic height system anyway - either all tabs in a tab-set are going to have to be forced to the intrinsic height of the largest member, or as you change tabs the height of the tab-set will change, potentially causing over/under flow events and scrollbar popping as it does so.

Hamish Friedlander 

On Feb 25, 2:22 pm, Hamish Friedlander <ham...@silverstripe.com>
wrote:

> > What isn't natural, or expected, for that matter, is forcing a fixed
> > height with a string of Javascript hacks every time the window size
> > changes. That's gotta go!
>
> While I agree that the current system is excessively javascript-heavy,
> there's nothing wrong with fixed-height systems if they're implemented
> right, and I disagree that we should discard it.
>
> I'm not saying tab nightmares are better for lots of data than scrolling,
> but if you're trying to fit that much data on a single page you're doing
> something wrong anyway, and I would hate to see the default experience
> crippled to compensate for the worst case.
>
> In particular, if you look at Design/ss3-ui_content-hd-resolution.jpg you
> can see the concept if is for the admin panel to float over the website (if
> your screen is big enough). Early prototypes show this is a _massive_ win
> for finding & editing content (the most common operation) for very little
> programming effort.
>
> But if we make the admin panel scrollable, that'll mean a scroll bar in the
> middle of the screen. And in my opinion, multiple scrollbars is way worse
> than fixed height layout.
>
> Hamish Friedlander

[Felipe Skroski]

Again thanks guys for all the feedback, 

we just released new screenshots on github to incorporate some of the ideas you suggested check them at 

https://github.com/silverstripe/silverstripe-design/tree/master/Design

here is a summary of ideas we're incorporating on this release

Scrolling

- The default system scrollbars are ugly interface bits, I won't argue with that...  But the act of scrolling is one of the most simple concepts of user interaction, be it a swipe of fingers, a mouse wheel, or even users that need to drag the ugly bar along, its a no brainer action... you dont need to find the read elements of the interface, interpret, point and click you simply scroll(or swipe).  The other huge bonus is the use of screen real estate, when a user is editing content for instance all the other options on the screen are noise for that action when you scroll you clean up the screen from unnecessary clutter. Is the easiest possible way to focus on a task. Maybe we could create  custom scrollbar kind of the one in twitter or on the iphone,  either way scrolling stays.

Accordion + hierarchy of actions

the accordion fits better with the vertical scrolling paradigm with it we created 4 level action flow to deal with edge cases 

   1) Main navigation 

   2) Secondary navigation 

   3) Tabs (no nested tabs here :) - it still doable for custom modules but not recommended)

   4) Accordion ( no nested accordions either )

Check : https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_editpage-content-complex.jpg

Fixed elements (still in discussion)

As you can see o the new screenshots there are some fixed elements like the main navigation and actions pannel. On the good side you keep the actions visible all the time and you don need to scroll up and down to navigate through the CMS. the down side is having the actions visible all the time (hehe) this creates visual clutter that's not useful on the context of editing a text for instance. 

we're more pending to the idea of having them fixed elements for now 

Inline help

the inline help is a great idea... 

widgets, 

not high priority right now but we'll get there at some point.

members, model admin

Hold tight we'll get there soon. 

List view new approach 

check it at https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_list-view.jpg it should be self explanatory

Action panel: right vs left (in discussion)

we're discussing two different positions to the actions panel on the left and the right. The right seems to be a more natural sequence {left to right}, but at the same time it can be a hassle for larger resolutions as it can be far away from the focal point, also some actions are not dependent of selection like new page for example.we're slightly tending to the left positioning but want to hear your opinion.

Check ou the new screenshots at https://github.com/silverstripe/silverstripe-design/tree/master/Design 

Looking forward to hear your thoughts

Cheers

Felipe

[Dan Rye]

Scroll Bars 

 - OSx Lion is moving to have scroll bars like iOS devices. (From MacRumors: http://images.macrumors.com/article/2010/10/25/030119-scrollbar.jpg)

 - Custom scrollbars can open a whole can of debate, but I think the best solution is allowing for custom scrollbars but in the end let the developer decide.

Fixed Elements

 - I personally like this

 - On the complex content screenshot I wanted to see save, publish, etc both up top and down where it currently is.  I'm not suggesting we make this fixed, but having the option to include the buttons at the top and bottom would be great.

Action Panel (Right vs Left)

 - I like the panel on the left, I think custom panels like the image panel launched from TinyMCE should go to the right.  

 - That being said, again the option to set the location could be nice.

Collapsable navigation

 - Do we loose this option when we go to the embedded  subnav?

 - I like the collapsed icon based menu, and the screen real estate that it gives back to the content area.

There is a lot of having my cake and eat it to here.  I realize one of the goals is that it is all easier to customize, so my hope is that some of these options are easy for the developer to tweak/add/etc.

Thank you Felipe (and the whole design team) for all the great work!

[Hamish Campbell]

On Feb 27, 8:30 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:
> *Action panel: right vs left (in discussion)*

> we're discussing two different positions to the actions panel on the left
> and the right. The right seems to be a more natural sequence {left to
> right}, but at the same time it can be a hassle for larger resolutions as it
> can be far away from the focal point, also some actions are not dependent of
> selection like new page for example.we're slightly tending to the left
> positioning but want to hear your opinion.

Hey Felipe, looking at the mockups I felt quite strongly that the
action panel should be on the left. When I saw the RHS option I
immediately thought that this must be an alternative I could set in
the CMS somewhere (ie dock the bar left or right).

To me it feels more natural to click the page and see a list of
actions to perform - it prompts me on what I can do with the current
selection. Then to the right of that is all the additional data I can
play with. It also feels like a more natural hierarchy of actions. As
Dan said it leaves the RHS as a natural place to put additional bars
like asset management and link insertion tools.

My 2c,

Hamish

[DesignCity]

A couple of queries (masquerading as suggestions),

On scrollbars and scrolling, I think you seem to be going down a good
path - menus and actions are fixed, while content scrolls. What I'm
not seeing currently is what happens to the TinyMCE editor with lots
of content - does the box scroll like it does currently or just get
really big and we scroll the entire box? I think this is one of the
major confusion points with the fixed vs scrolling interface argument
is this: if the content box has a fixed height and i've got a whole
heap of text that I have to scroll through within this tiny box, I
expect that you've done this to fit everything on one screen and I
don't want to scroll the interface as well. If however, the entire
content pane scrolls to show all of my content, then scrolling makes
sense. I prefer a tiny MCE field that increases for however much
content there is - It's trivial to use javascript to ensure the
tinyMCE formatting panel is always visible as you scroll a long
Content box and as I'll get to below, there are ways to ensure the
page actions are always visible.

On horizontal tabs, Is there a reason that we're using horizontal tabs
at all in ss3? Felipe has introduced this great new secondary-menu
horizontal set of tabs on the 'pages' view, and I would think we'd
want to keep the internal consistency here and reuse that paradigm.
The panel could also house the 'actions' for the current view (Save &
Publish, Preview, Save Draft, Move to Trash etc) which would keep all
actions within the CMS all in the one space. The side it appears on
will depend on too many things that haven't been visualised yet, so
there's no point getting too specific about this IMO.

On the vertical tabs, what is the reasoning for splitting up Content,
Settings and Reports under Edit Page for each page? Is there a
distinction between the Page Settings horizontal tab and the Settings
vertical tab (see ss3-ui_content-hd-resolution.jpg)? I can see that
perhaps the idea was to have only editable content under 'content' so
the settings and other bits aren't confusing someone simply editing
content, however wouldn't the Workflow, Access and Review tabs (and of
course Page Settings) also belong off the content tab?

Take it as food for thought rather than hard suggestions :)

Cheers,
Michael

On Feb 27, 3:30 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:
> Again thanks guys for all the feedback,
> we just released new screenshots on github to incorporate some of the ideas

> you suggested check them athttps://github.com/silverstripe/silverstripe-design/tree/master/Design

>
> here is a summary of ideas we're incorporating on this release

> *
> *
> *Scrolling*

> - The default system scrollbars are ugly interface bits, I won't argue with
> that...  But the act of scrolling is one of the most simple concepts of user
> interaction, be it a swipe of fingers, a mouse wheel, or even users that
> need to drag the ugly bar along, its a no brainer action... you dont need to
> find the read elements of the interface, interpret, point and click you
> simply scroll(or swipe).  The other huge bonus is the use of screen real
> estate, when a user is editing content for instance all the other options on
> the screen are noise for that action when you scroll you clean up the screen
> from unnecessary clutter. Is the easiest possible way to focus on a task.
> Maybe we could create  custom scrollbar kind of the one in twitter or on the
> iphone,  either way scrolling stays.

> *
> *
> *Accordion + hierarchy of actions*

> the accordion fits better with the vertical scrolling paradigm with it we
> created 4 level action flow to deal with edge cases
>    1) Main navigation
>    2) Secondary navigation
>    3) Tabs (no nested tabs here :) - it still doable for custom modules but
> not recommended)
>    4) Accordion ( no nested accordions either )
>

> Check :https://github.com/silverstripe/silverstripe-design/blob/master/Desig...
>
> *Fixed elements (still in discussion)*

> As you can see o the new screenshots there are some fixed elements like the
> main navigation and actions pannel. On the good side you keep the actions
> visible all the time and you don need to scroll up and down to navigate
> through the CMS. the down side is having the actions visible all the time
> (hehe) this creates visual clutter that's not useful on the context of
> editing a text for instance.
> we're more pending to the idea of having them fixed elements for now
>

> *Inline help*

> the inline help is a great idea...
>

> *widgets, *

> not high priority right now but we'll get there at some point.

> *
> *
> *members, model admin*

> Hold tight we'll get there soon.
>

> *List view new approach *
> check it athttps://github.com/silverstripe/silverstripe-design/blob/master/Desig...
> should be self explanatory
>
> *Action panel: right vs left (in discussion)*

> we're discussing two different positions to the actions panel on the left
> and the right. The right seems to be a more natural sequence {left to
> right}, but at the same time it can be a hassle for larger resolutions as it
> can be far away from the focal point, also some actions are not dependent of
> selection like new page for example.we're slightly tending to the left
> positioning but want to hear your opinion.
>

> Check ou the new screenshots athttps://github.com/silverstripe/silverstripe-design/tree/master/Design

>
> Looking forward to hear your thoughts
>
> Cheers
> Felipe
>

> *
> *

>
> On Sat, Feb 26, 2011 at 8:58 AM, Hamish Friedlander <ham...@silverstripe.com
>
>
>
> > wrote:

[Felipe Skroski]

On Mon, Feb 28, 2011 at 2:58 AM, Dan Rye <dan...@gmail.com> wrote:

Scroll Bars 

 - OSx Lion is moving to have scroll bars like iOS devices. (From MacRumors: http://images.macrumors.com/article/2010/10/25/030119-scrollbar.jpg)

 - Custom scrollbars can open a whole can of debate, but I think the best solution is allowing for custom scrollbars but in the end let the developer decide.

I agree let the system deal with the scrollbar... and if developers don't like the system scroll bar they can do their magic with javascript 

Fixed Elements

 - I personally like this

 - On the complex content screenshot I wanted to see save, publish, etc both up top and down where it currently is.  I'm not suggesting we make this fixed, but having the option to include the buttons at the top and bottom would be great.

Good call we'll incorporate that on the next round :) 

Action Panel (Right vs Left)

 - I like the panel on the left, I think custom panels like the image panel launched from TinyMCE should go to the right.  

 - That being said, again the option to set the location could be nice.

Collapsable navigation

 - Do we loose this option when we go to the embedded  subnav?

 - I like the collapsed icon based menu, and the screen real estate that it gives back to the content area.

No we don't loose it its more likely to become a popup navigation, anyway good question we need to address that 

[Felipe Skroski]

On Mon, Feb 28, 2011 at 8:18 AM, Hamish Campbell <hn.ca...@gmail.com> wrote:

On Feb 27, 8:30 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:
> *Action panel: right vs left (in discussion)*

> we're discussing two different positions to the actions panel on the left
> and the right. The right seems to be a more natural sequence {left to
> right}, but at the same time it can be a hassle for larger resolutions as it
> can be far away from the focal point, also some actions are not dependent of
> selection like new page for example.we're slightly tending to the left
> positioning but want to hear your opinion.

Hey Felipe, looking at the mockups I felt quite strongly that the
action panel should be on the left. When I saw the RHS option I
immediately thought that this must be an alternative I could set in
the CMS somewhere (ie dock the bar left or right).

Ok 2 votes for left, good idea to make it customizable but can't commit to that cos it may create some impact on the dev side and those guys are pretty busy already 

 

To me it feels more natural to click the page and see a list of
actions to perform - it prompts me on what I can do with the current
selection. Then to the right of that is all the additional data I can
play with. It also feels like a more natural hierarchy of actions. As
Dan said it leaves the RHS as a natural place to put additional bars
like asset management and link insertion tools.

We're trying to avoid a 3rd bar as much as we can to prevent an overloaded interface, the idea for the asset management is to become a lightbox as image galleries need a good real state to be 

displayed and when your're on the image selection context all the rest becomes noise...

but hold your thoughts on that for now cos the whole asset management is big part of SS3 and we just have some speculative wireframes so far... 

 

My 2c,

Hamish

[Felipe Skroski]

On Mon, Feb 28, 2011 at 3:20 PM, DesignCity <michael...@gmail.com> wrote:

A couple of queries (masquerading as suggestions),

On scrollbars and scrolling, I think you seem to be going down a good
path - menus and actions are fixed, while content scrolls. What I'm
not seeing currently is what happens to the TinyMCE editor with lots
of content - does the box scroll like it does currently or just get
really big and we scroll the entire box? I think this is one of the
major confusion points with the fixed vs scrolling interface argument
is this: if the content box has a fixed height and i've got a whole
heap of text that I have to scroll through within this tiny box, I
expect that you've done this to fit everything on one screen and I
don't want to scroll the interface as well. If however, the entire
content pane scrolls to show all of my content, then scrolling makes
sense. I prefer a tiny MCE field that increases for however much
content there is - It's trivial to use javascript to ensure the
tinyMCE formatting panel is always visible as you scroll a long
Content box and as I'll get to below, there are ways to ensure the
page actions are always visible.

 

Originally I was thinking you'd end up with 2 scrollbars one for the interface and another for Tiny MCE, although the idea of

increasing its size automagically to fit content size is great, we may need to check the implementation with our fellow core developers first..

 

On horizontal tabs, Is there a reason that we're using horizontal tabs
at all in ss3? Felipe has introduced this great new secondary-menu
horizontal set of tabs on the 'pages' view, and I would think we'd
want to keep the internal consistency here and reuse that paradigm.
The panel could also house the 'actions' for the current view (Save &
Publish, Preview, Save Draft, Move to Trash etc) which would keep all
actions within the CMS all in the one space. The side it appears on
will depend on too many things that haven't been visualised yet, so
there's no point getting too specific about this IMO.

When you ask to keep it consistent I agree as long as the consistency is relevant to the context. 

Context is much more important than consistency, examples: you don't dress consistently on a wedding and at the beach just for the sake of consistency do you ?

We're talking about 2 different contexts here 

1) Pages -  here is al about actions: select, drag and drop, delete reorganize everything is very mouse intensive, with enough real state to have the action bar on the left 

2) Edit page - here is all about updating, tweaking, writing, tabbing around form fields, a very keyboard intensive context, with the actual website on the far check right https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-hd-resolution.jpg and the need for space to accomodate content make the horizontal space luxury here

Using or not using tabs is a good question... I'm not a big fan of tabs but I have to admit they're good interface solutions for certain cases, we have to accomodate edge cases here that's why we created a 4 level division of actions that you can see at https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_editpage-content-complex.jpg, our deal here is to provide developers with tools in a flexible environment you could customize the CMS to not have tabs if you like  but if you need them they'll be there

 

On the vertical tabs, what is the reasoning for splitting up Content,
Settings and Reports under Edit Page for each page?

Again context based:

Content - everything about content / editing based(eg. text, title, blurb, featured image, banner, icon, video, audio ....)

Settings - everything about the page behavior / action based (eg. url, display in menu, visibiliti, allow comments, author, date, pagetype, access, )

Reports - All the information that a page may generate / read only (eg. google analytics stats, ab testing, e-commerce stats, error stats )

 

Is there a
distinction between the Page Settings horizontal tab and the Settings
vertical tab (see ss3-ui_content-hd-resolution.jpg)? I can see that
perhaps the idea was to have only editable content under 'content' so
the settings and other bits aren't confusing someone simply editing
content, however wouldn't the Workflow, Access and Review tabs (and of
course Page Settings) also belong off the content tab?

 

totally right that was my fault I forgot to update the screenshot on git now it's fixed check https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_editpage-content-complex.jpg 

[DesignCity]

Some excellent points Felipe.

This will be my last note on horizontal tabs.

It seems like the reasoning for horizontal tabs basically boils down
to screen realestate for the HD editing interface, If I understand you
correctly (you mention context, however I'm not sure I follow how
context dictates whether a tab bar be horizontal or vertical). That
interface (https://github.com/silverstripe/silverstripe-design/blob/
master/Design/ss3-ui_content-hd-resolution.jpg) certainly looks great,
however we personally don't have a single client that could run it on
their hardware today - and we have plenty of sites that are more
complicated than a single Content box and draw information like
products, floorplans, images etc from other DataObjects or other
pages. Because of this, I wouldn't want to see this interface guide
design decisions for the CMS no matter how awesome it is (and it
is!).

I know this is how it's historically been done in SS previously,
however I wouldn't like to see that blind us to the possibilities - if
there had never been an SS1 or SS2, would we, designing an interface
for SS, use horizontal tabs? To be clear, I'm absolutely fine if
that's the decision, just playing devils advocate :)

Cheers
Michael

On Feb 28, 12:38 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:

> the far check righthttps://github.com/silverstripe/silverstripe-design/blob/master/Desig...

> the need for space to accomodate content make the horizontal space
> luxury here
>
> Using or not using tabs is a good question... I'm not a big fan of tabs but
> I have to admit they're good interface solutions for certain cases, we have
> to accomodate edge cases here that's why we created a 4 level division of

> actions that you can see athttps://github.com/silverstripe/silverstripe-design/blob/master/Desig...,

> our deal here is to provide developers with tools in a flexible environment
> you could customize the CMS to not have tabs if you like  but if you need
> them they'll be there
>
>
>
> > On the vertical tabs, what is the reasoning for splitting up Content,
> > Settings and Reports under Edit Page for each page?
>
> Again context based:
> Content - everything about content / editing based(eg. text, title, blurb,
> featured image, banner, icon, video, audio ....)
> Settings - everything about the page behavior / action based (eg. url,
> display in menu, visibiliti, allow comments, author, date, pagetype, access,
> )
> Reports - All the information that a page may generate / read only (eg.
> google analytics stats, ab testing, e-commerce stats, error stats )
>
> > Is there a
> > distinction between the Page Settings horizontal tab and the Settings
> > vertical tab (see ss3-ui_content-hd-resolution.jpg)? I can see that
> > perhaps the idea was to have only editable content under 'content' so
> > the settings and other bits aren't confusing someone simply editing
> > content, however wouldn't the Workflow, Access and Review tabs (and of
> > course Page Settings) also belong off the content tab?
>
> totally right that was my fault I forgot to update the screenshot on git now

> it's fixed checkhttps://github.com/silverstripe/silverstripe-design/blob/master/Desig...

> ...
>
> read more »

[Chris Hope]

Originally I was thinking you'd end up with 2 scrollbars one for the interface and another for Tiny MCE, although the idea of

increasing its size automagically to fit content size is great, we may need to check the implementation with our fellow core developers first..

Given I just spent 8 hours today writing content using SilverStripe, and have been doing a lot of scrolling..., I think this is a fantastic idea. It's not something I'd really put much thought into before, but having to scroll down the interface and then scroll TinyMCE is irksome.

However, just thinking this through as I write, one issue with making the scrolling area be for the interface only with an auto-magical resize for TinyMCE, is that the TinyMCE toolbar could potentially be 100s (or 1000s) of pixels up the page. If you want to insert a link, for example, then you'd need to highlight the text, scroll up a *lot*, insert the link and then scroll back down again....

I think one scroll bar is a great idea *if* the toolbar could somehow be anchored so that no matter how far down you scroll you can still access it. And it needs to be remembered that there can be more than 1 TinyMCE instance on a page.

--
Chris Hope
The Electric Toolbox Ltd

Email: ch...@electrictoolbox.com
Web: www.electrictoolbox.com
Phone: +64 9 522 9531
Mobile: +64 21 866 529

[Martijn Van Nieuwenhoven]

I noticed as well with formatting content, adding links images etx, involves a lot of scrolling. I think adding a scrollbar to the Content field itself could solve this, so the toolbar is always visible. In this way editting content feels the same as working in a wordprocessor. (I did like the position in old SS versions, where always one toolbar is visible and works for all HTMLEditorFields: 1 bar for multiple fields...)

About the form buttons: I think most people will expect that buttons are below the forms, just like any other webform...

--

[Ingo Schommer]

Assuming that we come up with a modal dialog for media insertion

(rather than a persistent sidebar), TinyMCE's built-in fullscreen mode

will become more useful as well, eliminating the double scrollbar problem.

I think a TinyMCE window adjusting to the content height 

is not feasible, for the reasons Chris raised: Users will

get lost on the page with long content elements.

(there's an "autoresize" plugin for this purpose: http://www.springload.co.nz/love-the-web/tinymce-plugin-release-auto-resize/)

In terms of a "sticky" toolbar: We used to have one toolbar

to drive multiple TinyMCE instances in SilverStripe 2.2.

From memory, it needed too much customization.

You can have external (floating?) toolbars (demo: http://tinymce.moxiecode.com/tryit/external_toolbar.php),

but its unclear how that would work for multiple TinyMCE instances on the same page.

Perhaps a resize handle on the TinyMCE area would do the trick?

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23

[Chris Hope]

Perhaps it's best to leave it as it is then, although I do like the idea of being able to resize it, or perhaps it sizes itself based on the size of the viewport so at smaller resolutions we don't have it longer than the available height of the window.

Whatever the result, I'd ideally like to be able to drop an update of TinyMCE in when new updates are available to solve bugs and user experience issues with it. I use Chrome on Mac and it's usable most of the time but there are a number of issues which require me to edit html more than I'd like, and which I assume have probably been fixed in more recent versions of TinyMCE.

I believe at the moment this is difficult because there's some amount of customisation done to it to work with SS, which is why I assume it hasn't been updated in SS for some time. I did try dropping in an update myself some time back but it didn't work.

[Felipe Skroski]

Well I think we have enough good arguments to keep the scroll bar on TinyMCE, 

with that we can add auto resize to fill the height of the window and resizing handles.

Thanks for the feedback guys :)

[miiihi]

Hi guys, I really like the new design, but I think one important
feature is missing, that is language selector. For us non-english
speakers producing mostly multi lingual websites, this is really a key
feature...
Here are some my thoughts on it:
- installation of new languages should be done in code (or in some
config part of CMS), it should not be mixed with selector, as it is
now.
- selector could be also implemented as a part of tree, that is, first
level of tree would be language.
- subsites should also be considered in the same context - another
selector, part of tree...?

Keep up the good work!

miiihi

On Mar 1, 11:12 pm, Felipe Skroski <felipeskro...@gmail.com> wrote:
> Well I think we have enough good arguments to keep the scroll bar on
> TinyMCE,
> with that we can add auto resize to fill the height of the window and
> resizing handles.
>
> Thanks for the feedback guys :)
>
> On Tue, Mar 1, 2011 at 11:16 AM, Chris Hope <ch...@electrictoolbox.com>wrote:
>
>
>
>
>
>
>
> > Perhaps it's best to leave it as it is then, although I do like the idea of
> > being able to resize it, or perhaps it sizes itself based on the size of the
> > viewport so at smaller resolutions we don't have it longer than the
> > available height of the window.
>
> > Whatever the result, I'd ideally like to be able to drop an update of
> > TinyMCE in when new updates are available to solve bugs and user experience
> > issues with it. I use Chrome on Mac and it's usable most of the time but
> > there are a number of issues which require me to edit html more than I'd
> > like, and which I assume have probably been fixed in more recent versions of
> > TinyMCE.
>
> > I believe at the moment this is difficult because there's some amount of
> > customisation done to it to work with SS, which is why I assume it hasn't
> > been updated in SS for some time. I did try dropping in an update myself
> > some time back but it didn't work.
>

> > On 1 March 2011 11:05, Ingo Schommer <i...@silverstripe.com> wrote:
>
> >> Assuming that we come up with a modal dialog for media insertion
> >> (rather than a persistent sidebar), TinyMCE's built-in fullscreen mode
> >> will become more useful as well, eliminating the double scrollbar problem.
>
> >> I think a TinyMCE window adjusting to the content height
> >> is not feasible, for the reasons Chris raised: Users will
> >> get lost on the page with long content elements.
> >> (there's an "autoresize" plugin for this purpose:

> >>http://www.springload.co.nz/love-the-web/tinymce-plugin-release-auto-...
> >> )

> >> i...@silverstripe.com <andr...@silverstripe.com>

[Uncle Cheese]

I just got a look at the mockups for the filemanager. Wow! HTML5
uploads? That will be great!!

I can't believe what I'm seeing. What a huge improvement. Forget
SilverStripe 3.0.. this is like SilverStripe 5.0.

[Martijn Van Nieuwenhoven]

Woe.. yes. Im in love again!

I agree with Uncle Cheese. Can we get this in 2.4.6 ;)

[Ingo Schommer]

On 3/03/2011, at 12:29 AM, miiihi wrote:

> Hi guys, I really like the new design, but I think one important
> feature is missing, that is language selector.

Hey miihi, features for language selection are a bit off topic,
please start a new one for it.

[Felipe Skroski]

Hi all 

these are the very first concepts of the file manager 

there are still a number of issues to address, and we still need to clear some of those concepts

with our fellow core developers before announce them in a more official way, but that's our vision and hopefully it will be good to go

stay tunned there are more updates to come... 

Cheers

Felipe 

[@airforce@]

WOW, i have to say the SS 3.0 concepts looks so impressive.

It more likes a high-end industry CMS layout compared with Wordpress
and Drupal.

The new file manager is a stunner. Drop files for uploading is a great
user-experiences for most of clients.

Thanks for the effort that everyone have put in so far. Cannot wait to
see an stunning new verison soon!!!

On Mar 3, 9:53 am, Felipe Skroski <felipeskro...@gmail.com> wrote:
> Hi all
> these are the very first concepts of the file manager
> there are still a number of issues to address, and we still need to clear
> some of those concepts
> with our fellow core developers before announce them in a more official way,
> but that's our vision and hopefully it will be good to go
>
> stay tunned there are more updates to come...
>
> Cheers
> Felipe
>

[@airforce@]

WOW, i have to say the SS 3.0 concepts looks so impressive.

It more likes a high-end industry CMS layout compared with Wordpress
and Drupal.

The new file manager is a stunner. Drop files for uploading is a great
user-experiences for most of clients.

Thanks for the effort that everyone have put in so far. Cannot wait to
see an stunning new verison soon!!!



On Mar 3, 9:53 am, Felipe Skroski <felipeskro...@gmail.com> wrote:

> Hi all
> these are the very first concepts of the file manager
> there are still a number of issues to address, and we still need to clear
> some of those concepts
> with our fellow core developers before announce them in a more official way,
> but that's our vision and hopefully it will be good to go
>
> stay tunned there are more updates to come...
>
> Cheers
> Felipe
>

[Chris Bryer]

Out of curiosity, has anyone put any thought towards letting
developers resize the width of tinyMCE, per HtmlEditorField instance?
Having a set width of tinyMCE will let users more accurately and
easily line up images in text. I've had htmlEditors for sidebar
content (width ~250px) and editing content in tinymce on a widescreen
is just not realistic and not representative of what it will look like
on the live site. sticking images in there can be tough to understand
where they will land.

i know that we can sort of do it through HTMLEditorConfig however the
minimum width is around 500px if i remember right. i have a work
around where i require a css file in getCMSFields that looks like
this:

#Content.htmleditor tr.mceLast td.mceLast iframe{
width:226px !important;
}
the only problem with this approach is that the content area may need
to be different widths between pages with or without a sidebar. the !
important declaration makes it pretty messy to change dynamically and
isnt really ideal.
just wanted to throw this question out there. i havent seen any
plugin for tinymce that does this, but it can be really helpful to
have an appropriately sized content area during editing.

Thanks,
-Chris

[Chris Hope]

I add this to my editor.css file (at /themes/[name]/css/editor.css) to set the width of the content in the TinyMCE and it works just fine to e.g. set the content to 650px wide:

.typography {

width: 650px;

}

While the html editor is still the full width, the content will wrap at 650px.

You can also add a bunch of other stuff to this file so it appears in the style drop down boxes. Maybe it's supposed to be in typography.css? But it works for me in editor.css and I personally don't use the typography.css file in my frontend anyway.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Chris Bryer]

i've seen that approach before, however you cant control in css
whether or not there is a sidebar which would affect width. also,
having a boundary on the left but not the right feels a little odd
when using it. i usually check menu(1) or query for sidebar related
info in php, then depending on the result I'll require one of two
style sheets that have the corresponding width. the !important
declaration messes things up though, and you have to refresh the
browser for the content area to be set right when switching between
pages with a sidebar vs a fullscreen content area.

I guess i'm just curious if many other developers end up trying to set
the width of the htmleditorfield or just use it as it is. Ive seen a
few customers get frustrated because the layout that they see while
editing isnt what they see on the front end, and I usually try to
match them as close as i can. it seems like a natural thing to try to
simulate in the backend of a cms, and to me its odd that so many cms's
don't do this.

-Chris

[Chris Hope]

Setting the width of the content in the html editor as I suggested works just fine for me, and although there is white space on the right side of the editor, the width of the content in the editor exactly matches the width of the content in the frontend. I work with my own SS websites writing content about 15 to 20 hours a week and using my method has always worked just fine.

-Chris

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[DesignCity]

> I think one scroll bar is a great idea *if* the toolbar could somehow be
> anchored so that no matter how far down you scroll you can still access it.

Keeping the TinyMCE panel always visible while the content box is on
the screen is pretty simple, a few lines of jquery to change the
position and you're there.

Personally I found the single toolbar for multiple fields really
confusing - it sat above all fields on the page and a user could never
tell what fields they could use it in.

> I think a TinyMCE window adjusting to the content height
> is not feasible, for the reasons Chris raised: Users will
> get lost on the page with long content elements.

I wholeheartedly and respectfully disagree with this. Users will know
*exactly* where they are on the page because they'll be staring right
at their content. I see it as working exactly the way a long website
would work - if the content on a website is 10 screens long, I scroll
down and judge the location by the scrollbar height. I'm putting
forward the same might work within the CMS. Having said that,
autoresize would really be a huge step forward in its own right.

Agree with many of these comments, these mocks are looking fantastic!
Very excited for the first alphas/betas!

Michael

[Sam Minnée]

Yeah, the only problem with having the TinyMCE field stretch to accommodate the content is that you end up losing the toolbar. Implementing a tweak so that the toolbar is never able to scroll off the top of the page would make that the best solution.

Felipe - I don't think this needs to be reflected in the mock-ups; it can be done within JavaScript code.

Thanks,
Sam

On 4/03/2011, at 2:27 PM, DesignCity wrote:

>> I think one scroll bar is a great idea *if* the toolbar could somehow be
>> anchored so that no matter how far down you scroll you can still access it.
>
> Keeping the TinyMCE panel always visible while the content box is on
> the screen is pretty simple, a few lines of jquery to change the
> position and you're there.
>

[spronk]

Agreed with Uncle Cheese about getting rid of nested tabsets.

How about looking at the model used to shift preference editors from
nested tabs to something better? I.e. a vertical and horizontal set.

The file interface has this folders/tags secondary panel on the left,
to the immediate right of the CMS navigation.

Have you thought about using a side panel in this area to declutter
the tab interface? I would take this over accordian tabs (which are
awkward to use, more difficult to implement, especially considering
using multiple browser tabs).

Keith

On Feb 24, 4:26 am, Uncle Cheese <aaroncarl...@gmail.com> wrote:
> I'd like to strongly discourage the use of nested tabsets. They look
> awful, they're a poor use of space, and users can't figure them out.
>
> Consider a single set of horizontal tabs and when there are a large
> number of fields on a given tab, use a nested set of vertical tabs, or
> headings that blind down a set of fields. You might call it an
> "accordion" in the jQuery world. Something like that would be much
> more practical than continuing the nested tab adventure.
>
> On Feb 23, 4:57 am, Felipe Skroski <felipeskro...@gmail.com> wrote:
>
> > On Wed, Feb 23, 2011 at 9:13 PM, Michael Andrewartha <
>
> > mich...@silverstripe.com> wrote:
>
> > >> 2) after delete it's gone (I need to double check that with devs though)
> > >> as if you create
> > >> you can simply delete if it was an accident.
>
> > > Not quite... just use the "All pages including deleted" option in the tree
> > > Show dropdown to find your deleted pages and revert your pages from there.
> > > No page is technically deleted as there is always a copy of it in the page
> > > version history. Its great to show clients this option as I get the "oh no
> > > I've deleted a page, what do i do..." question a lot : )
>
> > well if people request for support is because they are completely lost, this
> > is not good. If they can recover the file we need to rename the action, it
> > needs to be called 'move to trash' instead of 'delete' so there won't be
> > ohhs and ahhs when you do the action, people will simply think "ok now where
> > is the trash?" and that should be obvious either so users will be happier
> > and you save your time not answering that anymore :)
>
> > >>  Q3) The tabs issue is an information architecture issue, the way to
> > >> reduce the number of tabs is by having more content per tab, the
> > >> biggest mistake I see now is people creating tabs to add 1 txt
> > >> field...
>
> > > Another thing to think about here is better ways to structure fields inside
> > > tabs. Tabs only go so far with structuring fields and the less tabs the
> > > better, however if fields aren't structured well inside the tab then its
> > > best if you just create more tabs as they are more obvious when you click on
> > > a page : )
>
> > > In my experience with adding too many items inside one tab, users don't
> > > automatically think of scrolling down to find fields so they have a quick
> > > look in each tab and if it isn't obvious to them, they will get frustrated
> > > and ask where they are supposed to edit a section of the website rather then
> > > spending time looking for it themselves.
>
> > Structuring fields is something every developer should carefully think
> > about, we can provide good defaults for common elements, standards,
> > guidelines, ui components, but given the flexibility of this new version you
> > can build whatever you want on top of it and that is devs responsibility to
> > make it usable at least.
>
> > In my experience people scroll a lot. 1) scrolling is a no brainer you can
> > use the mouse wheel of a finger swipe much easier than reading,
> > interpreting, pointing the mouse on the right place and clicking. 2) get the
> > 3 main websites of the planet google, facebook and twittter, all of them
> > people need to scroll and we're talking about probably 90% of internet users
> > here if not more. 3) read these articles:http://iampaddy.com/lifebelow600/andtrythis sitehttp://www.thereisnopagefold.com/. If after that you still think people
> > don't scroll please give me good sources to support that.
>
> > Although there is one thing I agree with you, we need to make the page look
> > scrollable which is not the case today.
>
> > >> @All: I'm looking for edge cases now so if you have an interface
> > >> totally bloated with options send me screenshots :)
>
> > > Haha looks like that screenshot has an extreme case of tabulitis :D (sorry
> > > for the bad pun)
>
> > sure that is a decent UI challenge but we're on the right track to get that
> > sorted.
>
> > >> Cheers
> > >> Felipe
>
> > >> On Feb 23, 10:13 am, Sam Minnée <s...@silverstripe.com> wrote:
> > >> > > UI wise I see a big emphasis on the Workflow in one of the Page
> > >> > > views.  Workflow hasn't been a big need for our clients but maybe this
> > >> > > is a common request?  I could see this being very useful in bigger
> > >> > > sites.
>
> > >> > Workflow is a module; the reason they've been included in the mock-up is
> > >> to show how the design can handle a large number of custom actions.  As much
> > >> as designing a specific UI we're also designing a framework that other
> > >> modules will plug into.
>
> > >> > The specific list of buttons was derived from the existing cmsworkflow
> > >> module, although Marcus et al have been working on an advancedworkflow
> > >> module that looks quite promising.
>
> > >> > At this stage I wouldn't worry too much about the workflow related
> > >> stuff; we're focusing on the core product first.

>
> > >> --
> > >> You received this message because you are subscribed to the Google Groups
> > >> "SilverStripe Core Development" group.
> > >> To post to this group, send email to silverst...@googlegroups.com.
> > >> To unsubscribe from this group, send email to
> > >> silverstripe-d...@googlegroups.com.
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/silverstripe-dev?hl=en.
>
> > > --

> > > Michael Andrewartha | Developer
> > > SilverStripe
> > >http://silverstripe.com
>
> > > Phone: +64 4 978 7330 #53

[malte@eos]

On 25 Feb., 20:33, Hamish Friedlander <ham...@silverstripe.com> wrote:
> > Widgets: At the moment, some work is needed in order to add widgets into
> > 2.4 which shouldn't really be the case as widgets are a big part of the CMS,
> > however at the moment they just seem to be tacked onto the end and get lost
> > with everything else. Is the idea for 3.0 to better integrate widgets into
> > the CMS and how should this look like?
>
> The problem is that take 100 people, and you'll get 150 ideas about how
> widgets should work. Some people just want small tweaks to the current
> system, some people want template-snippet injection, some people want full
> GUI layout / template edit tools.
>
> While it'd be cool to have a new widget system in 3, I can just see it
> causing massive delays while we try to hash out the details.
>
> There's nothing API breaking about adding a widget system, so I'd rather see
> us add APIs that make writing widget-style modules easy (including things
> like the thread on injecting widgets into tinymce). Then let people write
> modules for how they think widgets should work, & crown the winner
> victorious.
>

The main problem is not a proper widget-system, but a better support
for all kinds of subforms/widgets/subdataobject in a form. So an
DataObject could be easily editable within an other DataObject. The
rest is some JS and CSS.

Additionally it would be nice, if you are dublicating a page, you
could decide, which related objects are dublicated and which are just
linked to the first object.


Regards,

Malte

[Felipe]

just added a new topic to discuss a new release with some of your feedback incorporated please check 

https://groups.google.com/d/topic/silverstripe-dev/WwYg2KrJ0Mw/discussion