> 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/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 at
> https://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 at
> https://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:

>> On 26 February 2011 08:38, Uncle Cheese <aaroncarl...@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

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

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

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