New design stuff on github

[Felipe]

Hi All
We've been quiet on the forum for few weeks but we've been committing new designs almost every day.

Here's a breakdown of the last changes and updates:

Dialogs and tone
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_dialogs.jpg 

The dialogs are quite straight forward in terms of design but they were probably the first time we touched the topic of tone
of communication of SS 3. We're proposing the end of R2d2 like communication a avoiding those awful "Server error 2345" for the user
that is meaningless the tone we're trying to set is personal and human much more like a dialog than a system talk. Those dialogs are just the first cut
and probably Jo (our writer) will help us polishing those messages.

Inserting links from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_insert-link.jpg
That is self explanatory as you change the dropdown on item one the fields on item 2 will change too

Inserting images from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-computer.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-web.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-files.jpg

When devs ask me to create some concepts for when you add images from tiny MCE I was thinking: "oh that should be simple.."
but really, that is hardcore stuff gave me some headaches but I think we've got to a good solution. Here's a breakdown of concepts applied

- Multiple file upload
- html5 Drop to upload, straight from your desktop to the cms
- Editing during upload, while you wait the upload you can add title, tags etc
- Inserting multiple images at once, as we moved from sidebar to modalbox that's necessary to avoid opening ang close the popup all the time
- Images from a url, multiple urls with live preview
- Images from a Files manager, aslo multiple files with search and browse functionality


Version history
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_editpage-history.jpg

Following quite close what we currently have its more a cosmetic change really.


Model admin / datagrid
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_model-admin.jpg

using the custom datagrid for pages we created the generic one that can be used on any model admin
I think the screen-shot is self explanatory

Let me know if you have questions or thoughts

Cheers
Felipe

[Chris Hope]

Can we please have the ability to set rel=nofollow when inserting a
link. I've managed to make it work myself for SS 2.4 but it would be
wonderful if it was actually part of SS 3.

> --
> 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 Hope
The Electric Toolbox Ltd

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

[Jason Stratford]

Second the ability for setting the rel attribute, just not limited to nofollow, also maybe an advanced mode that allows the addition of custom classes and javascript for things like custom tracking systems. One of our clients uses 5 different tracking systems that all like to be able to add javascript to links in some way or other (don't ask why they use 5 systems, just go with it. We have had to in the end). Probably an extreme case, but it would be useful to do in the popup rather than having to edit in HTML mode.

[Marcus Nyeholt]

Do you actually mean being able to add arbitrary attributes to the image tag? 

Cause that would be very handy. 

[Jason Stratford]

yup useful on Image tags as well, but its primarily link tags that we see this kind of usage in the main. I know you can do all sorts of freaky stuff with TinyMCE config, but I think this is a UI issue that needs to be addressed rather than a consistent mapping in the config.

[Ingo Schommer]

Hey Felipe,

On Tuesday, March 29, 2011 5:19:12 PM UTC+13, Felipe wrote:

Dialogs and tone
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_dialogs.jpg 

The dialogs are quite straight forward in terms of design but they were probably the first time we touched the topic of tone
of communication of SS 3. We're proposing the end of R2d2 like communication a avoiding those awful "Server error 2345" for the user
that is meaningless the tone we're trying to set is personal and human much more like a dialog than a system talk. Those dialogs are just the first cut
and probably Jo (our writer) will help us polishing those messages.

I really like this, although we should ask some of our more corporate customers how they feel about the language.

Its a fine line between an informal and unprofessional tone - Jo will be able to help there.

We *could* make a separate locale for this (en_US vs. en_US_informal),

but that could double the amount of translatable entities we have to maintain.

Translators would need to pick one of the two "master languages" to base their translation on.

which further complicates things (plus, translate.ss.org doesn't support this use case).

So, long story short: I'd really really prefer a single consistent locale=language setting in the CMS :)

Inserting links from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_insert-link.jpg
That is self explanatory as you change the dropdown on item one the fields on item 2 will change too

Inserting images from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-computer.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-web.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-files.jpg

When devs ask me to create some concepts for when you add images from tiny MCE I was thinking: "oh that should be simple.."
but really, that is hardcore stuff gave me some headaches but I think we've got to a good solution. Here's a breakdown of concepts applied

Hm, is inserting multiple images at once a good default use case in a rich text editing context?

I guess it could be a simple way to get a gallery going without any additional modules,

but could also clutter the content field once you hit "insert".

Was this on purpose, or more an easier way to transfer the "files & images" interface to this new popup interface?

I assume that we just take the form in the lower part for a panel to edit an existing image, right?

I don't think we need to allow replacing an image in TinyMCE just yet, delete+insert is fine

(and your designs are already enough work to implement haha)

Model admin / datagrid
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_model-admin.jpg

using the custom datagrid for pages we created the generic one that can be used on any model admin
I think the screen-shot is self explanatory

I can see the motivation for having the filter panel as a UI element on the data grid rather than

the "surrounding" model admin UI, but we have to cater for use cases with at least double the amount of filters

(typical CRM-style model admins have this). Would you see the filter panel scrollable? Sounds ugly...

@Sam: Can you think of any reason that we should keep ModelAdmin::$managed_models with multiple models

in a two-level hierarchy like in 2.4, or could we condense all of them into toplevel menu entries? 

Example:

class ModelAdmin1 { static $managed_models = array('Model1', 'Model2');}

class ModelAdmin2 { static $managed_models = array('Model3', 'Model4');}

Old style menu:

- ModelAdmin1

  - Model 1

  - Model 2

- ModelAdmin2

  - Model 3

  - Model 4

New style menu:

- ModelAdmin1: Model 1

- ModelAdmin1: Model 2

- ModelAdmin2: Model 3

- ModelAdmin2: Model 4

Ingo

[Mat Weir]

"and your designs are already enough work to implement haha"

Love it, the eternal war between designer and developer. 

[Artyom]

now now... I prefer to see it as "dialectical synergy" 

:- )

On Tue, Mar 29, 2011 at 3:31 PM, Mat Weir <mat....@xebidy.com> wrote:

"and your designs are already enough work to implement haha"

Love it, the eternal war between designer and developer. 

On 29/03/2011, at 10:50 PM, Ingo Schommer <in...@silverstripe.com> wrote:

and your designs are already enough work to implement haha

--

[Uncle Cheese]

I don't know that these designs are necessarily representative of a
determinate feature set. I think we're more talking about the general
UI/look-and-feel, and ancillary elements like rel tags can be added
later once we iron out the UI.

This all looks really good. The TinyMCE features in a modal window is
a beautiful thing. The current "panel" approach makes me queasy. :-)

Couple things -- The "filters" in modeladmin/datagrid should be
exposed. ModelAdmin/DataGrid are interfaces that invite manipulation,
so knowing the current state is critical. It's really confounding to
see a list and wonder why last week's record isn't in there, only to
find that there's a residual filter keeping it out of the result set
that you can't see. I want to see those filters at all times.

File manager -- The progress bars are a little gradient-happy. In
general, I think there's just a little too much design happening, and
I think it could be a little more subtle.

On Mar 29, 6:51 am, Artyom <artyom...@gmail.com> wrote:
> now now... I prefer to see it as "dialectical synergy"
>
> :- )
>
>
>
> On Tue, Mar 29, 2011 at 3:31 PM, Mat Weir <mat.w...@xebidy.com> wrote:
> > "and your designs are already enough work to implement haha"
>
> > Love it, the eternal war between designer and developer.
>

[Artyom]

One thing my clients seem to trip on is the connection between the Title and URL that is generated.  Looking at your designs, I thought that the URL might be moved from the metadata tab and exposed more directly, perhaps as a read only field that changes as you type the title or something... and then to "override" the default behavior, you could have a "change" button that makes it writable.

The issue being that clients often don't realize they are changing the URL even with the current popup in 2.4... and it then breaks google search of their site etc... or just ends up in long ugly URL's.

Might there be some other UX solution to this that either makes it more explicit (but also painless for default cases)

[Uncle Cheese]

Yeah, I agree with that. And how annoying is that popup? I think the
url segment should be persistent on the edit form..

On Mar 29, 12:12 pm, Artyom <artyom...@gmail.com> wrote:
> One thing my clients seem to trip on is the connection between the Title and
> URL that is generated.  Looking at your designs, I thought that the URL
> might be moved from the metadata tab and exposed more directly, perhaps as a
> read only field that changes as you type the title or something... and then
> to "override" the default behavior, you could have a "change" button that
> makes it writable.
>
> The issue being that clients often don't realize they are changing the URL
> even with the current popup in 2.4... and it then breaks google search of
> their site etc... or just ends up in long ugly URL's.
>
> Might there be some other UX solution to this that either makes it more
> explicit (but also painless for default cases)
>

[Felipe]

Hey Ingo,

On Tuesday, March 29, 2011 10:20:36 PM UTC+13, Ingo Schommer wrote:

Hey Felipe,

On Tuesday, March 29, 2011 5:19:12 PM UTC+13, Felipe wrote:

Dialogs and tone
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_dialogs.jpg 

The dialogs are quite straight forward in terms of design but they were probably the first time we touched the topic of tone
of communication of SS 3. We're proposing the end of R2d2 like communication a avoiding those awful "Server error 2345" for the user
that is meaningless the tone we're trying to set is personal and human much more like a dialog than a system talk. Those dialogs are just the first cut
and probably Jo (our writer) will help us polishing those messages.

I really like this, although we should ask some of our more corporate customers how they feel about the language.

Its a fine line between an informal and unprofessional tone - Jo will be able to help there.

We *could* make a separate locale for this (en_US vs. en_US_informal),

but that could double the amount of translatable entities we have to maintain.

Translators would need to pick one of the two "master languages" to base their translation on.

which further complicates things (plus, translate.ss.org doesn't support this use case).

So, long story short: I'd really really prefer a single consistent locale=language setting in the CMS :)

Regarding the tone I prefer to be unprofessional and effective than professional and meaningless... everyone knows how to have a personal and relaxed dialog
but not everyone understand corporate language so I still advocating the personal tone. That said I'm not a pro writer like Jo and on my cut I probably went to far on some
jokes but that was more to set the spirit than the correct words, we can be personal without being jokey and Jo will help us on that...

About the en_US vs. en_US_informal, no I'm not proposing that ... I'm proposing only one tone that's accessible to all doesn't matter if you work in a trillion dollar corporation or if you have a travel blog
an that tone is personal, human, warm, cheerful and fun. Agree with you only one consistent locale.

 

Inserting links from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_insert-link.jpg
That is self explanatory as you change the dropdown on item one the fields on item 2 will change too

Inserting images from tiny mce
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-computer.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-web.jpg
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_content-add-image-from-files.jpg

When devs ask me to create some concepts for when you add images from tiny MCE I was thinking: "oh that should be simple.."
but really, that is hardcore stuff gave me some headaches but I think we've got to a good solution. Here's a breakdown of concepts applied

Hm, is inserting multiple images at once a good default use case in a rich text editing context?

The default is in fact one image that's a simulation of an edge case. Users can add one at time  or several at the same time. Why is that useful?
Say I have my portfolio site where images are the main content I prefer to upload them at once, and then add the text around them, or a travel blog
I have several images that I want to upload an then start writing because the story flows around the images. These are cases were multiple file upload is useful.
If you want to add one at time is also possible.
 

I guess it could be a simple way to get a gallery going without any additional modules,

but could also clutter the content field once you hit "insert".

Was this on purpose, or more an easier way to transfer the "files & images" interface to this new popup interface?

On purpose for the reasons above

I assume that we just take the form in the lower part for a panel to edit an existing image, right?

Yep that's right, we may need an icon on top of the image when you select it to say it's editable maybe...
 

I don't think we need to allow replacing an image in TinyMCE just yet, delete+insert is fine

(and your designs are already enough work to implement haha)

That's fine for now, we could leave this for further versions of SS or a good soul on the community could do it :D
 

Model admin / datagrid
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_model-admin.jpg

using the custom datagrid for pages we created the generic one that can be used on any model admin
I think the screen-shot is self explanatory

I can see the motivation for having the filter panel as a UI element on the data grid rather than

the "surrounding" model admin UI, but we have to cater for use cases with at least double the amount of filters

(typical CRM-style model admins have this). Would you see the filter panel scrollable? Sounds ugly...

 

I'm not 100% happy with that solution. If the filters are so massive they couldn't fit on the screen the could be a
modalbox with a scroll. The problem with the modalbox is that you're not actively filtering the list the filter is a separate
process. I thought about having a side panel with a scroll just like this https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_pages-list-view.jpg
but then we have the edge case of having several datagrids in one view in that case the sidepanel looses context.  A third solution could be having the filter to slide down inside
the datagrid space, maybe I'll try that for a second iteration...

 

[Felipe Skroski]

About the whole attributes on images thing I like the idea of being more flexible
about is and make possible to add things like nofollow, javascript, classes but
I don't like the idea of exposing those advanced fields to normal users and even the idea of having them as fields
is not that flexible... what if we have a advanced mode that allow you to change the html tag that is going to be inserted
adding javascript, ids, classes and whatever sort of crazy attributes...?

[Felipe Skroski]

Hi Uncle cheese,

On Wed, Mar 30, 2011 at 2:43 AM, Uncle Cheese <aaronc...@gmail.com> wrote:

I don't know that these designs are necessarily representative of a
determinate feature set. I think we're more talking about the general
UI/look-and-feel, and ancillary elements like rel tags can be added
later once we iron out the UI.

This all looks really good. The TinyMCE features in a modal window is
a beautiful thing. The current "panel" approach makes me queasy. :-)

Couple things -- The "filters" in modeladmin/datagrid should be
exposed. ModelAdmin/DataGrid are interfaces that invite manipulation,
so knowing the current state is critical. It's really confounding to
see a list and wonder why last week's record isn't in there, only to
find that there's a residual filter keeping it out of the result set
that you can't see. I want to see those filters at all times.

Agree with you the current solution is not good enough...
but making the filters persistent creates a big ui challenge to fit
more information than a user and even a screen can handle
there was the option of using something like pages/list view...
https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_pages-list-view.jpg
but with multiple datagrids in a view that doesnt work, I'll try a top bar sliding thing
inside the datagrid to see how it looks like, but is easy to anticipate that scrolling up and down may be necessary on big filters...

Let me know it you can think of something better :)

Cheers
Felipe
 

[Jason Stratford]

I agree that an advanced mode/tab is a good solution to hide most of the complex stuff from casual users, but exposing it as the ability to just edit the tag directly allows for human error to creep in to the actual markup breaking things rather easily. For that reason I would still prefer the advanced mode to be structured. For really deep editing there is always the HTML mode in the editor as a whole. We have a class of user that is savvy enough to add in extra attributes under guidance, but not skilled enough to trust with raw HTML editing. Too easy to miss of a quote or something that can break things in strange ways that are hard to find.

[Chris Hope]

I like the idea of being able to "lock" the URL so it can't suddenly
change and break hard-coded navigation, or other such things. It
wouldn't need to be locked by default, just the ability to so, so the
human CMS editor can't accidentally damage the way things might be set
up.

On one of the sites I am involved with, they changed the name/title
field of the homepage (no, I don't know why they did this as it has no
effect on the site whatsoever, but they did it because they could),
and must have clicked ok on the dialog that pops up without realising
what they were actually doing. So the URL changed and the end result
was a 301 redirect from / to /foo-bar-baz/ which isn't really ideal.

--

[Chris Hope]

On 30 March 2011 19:01, Jason Stratford <ja...@alteredminds.com> wrote:
> I agree that an advanced mode/tab is a good solution to hide most of the
> complex stuff from casual users,

I like this idea.

> but exposing it as the ability to just edit
> the tag directly allows for human error to creep in to the actual markup
> breaking things rather easily.

Agreed. For me personally, and the reason I brought this up in the
first place, is I want to be able to set a link rel="nofollow" without
having to mess around looking through the source code to find the link
and add it, and instead simply select from a radio option. As I
mentioned in my earlier email, I have implemented this myself but I
would rather this sort of thing actually be part of the core system. I
do think it's a good idea to be able to hide this sort of stuff from
most users.

> For that reason I would still prefer the
> advanced mode to be structured. For really deep editing there is always the
> HTML mode in the editor as a whole. We have a class of user that is savvy
> enough to add in extra attributes under guidance, but not skilled enough to
> trust with raw HTML editing. Too easy to miss of a quote or something that
> can break things in strange ways that are hard to find.

Agreed. I am obviously one of those editors savvy enough to edit the
HTML myself (I'm a developer and a content writer) but I'd rather not,
as I talked about above.

My $0.02 :)

[aram balakjian]

Isn't this a question of differentiating between a simple datagrid on a page (i.e. DOM in 2.4) and the Model Admin grid? A simple datagrid on a page could have the dropdown filter like in the designs as there may be multiple on a page and it is unlikely to have huge filters (in 2.4 there are pretty much no options for filtering anyway). Then Model Admin would have it's own persistent filter as there is never going to be more than one on a page and the filter could get quite extensive?

I think it is also actually quite important to have a difference in the UI design of these elements to avoid confusion between datagrids that might be on a DataObject managed in ModelAdmin and the actual Model Admin grid that lets you access that DataObject. As a user, I might click on one of those dataobjects and strait away be presented with a datagrid on that object. If they look the same, I could imagine that being quite confusing.

Aram

[Ingo Schommer]

On Wednesday, March 30, 2011 9:25:45 PM UTC+13, Aram wrote:

I think it is also actually quite important to have a difference in the UI design of these elements to avoid confusion between datagrids that might be on a DataObject managed in ModelAdmin and the actual Model Admin grid that lets you access that DataObject. As a user, I might click on one of those dataobjects and strait away be presented with a datagrid on that object. If they look the same, I could imagine that being quite confusing.

Hey Aram, that brings up a good point: So we'll have a DataGrid class with search/add/edit/pagination - how different is that from a full-fledged ModelAdmin actually? I can only come up with two additional features: CSV Import and managing multiple models in the same UI. CSV Import could be a DataGrid "module", multiple models was really more of a clutch to work around the limitations in the top navigation bar.

So if we see ModelAdmin in 3.0 as a "DataGrid with rearranged UI components", we could save ourselves a lot of code duplication - and also allow for "instant ModelAdmins" embedded in other contexts like Page->getCMSFields().

Just thinking out loud here, I think we need to get into DataGrid requirements gathering and API design first to see how much overlap there actually is.

[Sam Minnée]

I think is a good indication that much of the internal API for these two points; however I think it's important that we fall into the over-abstraction trap.

In particular, I think there's a difference, to a user, of having a single "keyword" search field a list of of members (e.g., the current MemberTableField), and having a side-panel of 10 different search options for really in-depth exploration of a data-set (which is often the case for a ModelAdmin).

Speaking at a high-level, I could imagine that the implementation of these two variants could be done as a different set of templates/css/js: one in which the form was a permanent side-bar, and one in which is was a pop-up.

- I think that we should design a screen that only works when you have a single data-grid on the screen, for those parts of the application that really call for focused analysis of a single data-set. A side-bar would work here, but I don't want to get prescriptive with the design.

- I think that the filter button + popup is an excellent way of embedding modeladmin-like functionality into a data-grid.

- From a practical perspective, I would expect us to implement one of these first - most likely the filter button + popup - and implement the second one later. Implementation of the second one would be a good mini-project and could be loaded into a ticket at the appropriate time. (I would expect this to be post-alpha)

- I see no need to make the two items visually distinct. Only programmers care about the differences between ModelAdmin and DataObjectManager. The important thing to users is how frequently they need to choose the filters - is it an occasional tool, or something they use every day?

[Simon J Welsh]

On 29/03/2011, at 5:19 PM, Felipe wrote:

> *- Multiple file upload*
> *- html5 Drop to upload*, straight from your desktop to the cms
> *- Editing during upload*, while you wait the upload you can add title, tags
> etc
> *- Inserting multiple images at once*, as we moved from sidebar to modalbox

> that's necessary to avoid opening ang close the popup all the time

> *- Images from a url, *multiple urls with live preview
> *- Images from a Files manager, *aslo multiple files with search and browse
> functionality

Can we get some designs for what file uploading will look like without the File API? Especially since most browsers don't support it.
---
Simon Welsh
Admin of http://simon.geek.nz/

Who said Microsoft never created a bug-free program? The blue screen never, ever crashes!

http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e

[Uncle Cheese]

You may already be aware of it, but I'd like to recommend Plupload
http://plupload.com as an HTML5/Flash upload wrapper. It detects what
is the best engine to use and creates a customisable interface based
on that. So Safari gets the HTML5 uploader with the drag-and-drop,
while IE falls back on a Flash uploader, etc. If you have GoogleGears
installed, it will use that, too.

It just seems to do all the work that I don't want to do when dealing
with the varying support for uploading.

On Mar 31, 3:21 am, Simon J Welsh <welsh.si...@gmail.com> wrote:
> On 29/03/2011, at 5:19 PM, Felipe wrote:
>
> > *- Multiple file upload*
> > *- html5 Drop to upload*, straight from your desktop to the cms
> > *- Editing during upload*, while you wait the upload you can add title, tags
> > etc
> > *- Inserting multiple images at once*, as we moved from sidebar to modalbox
> > that's necessary to avoid opening ang close the popup all the time
> > *- Images from a url, *multiple urls with live preview
> > *- Images from a Files manager, *aslo multiple files with search and browse
> > functionality
>
> Can we get some designs for what file uploading will look like without the File API? Especially since most browsers don't support it.
> ---
> Simon Welsh

> Admin ofhttp://simon.geek.nz/

[Richard Ward]

I can second that - i've integrated plupload a couple of times and found it to be very easy to get running across multiple browsers, and helps overcome any max upload size limitations you may have along the way.

[Sigurd Magnusson]

What's the support that IE9 has in terms of drag and drop file uploads?

[Simon J Welsh]

On 1/04/2011, at 3:40 AM, Uncle Cheese wrote:

> You may already be aware of it, but I'd like to recommend Plupload
> http://plupload.com as an HTML5/Flash upload wrapper. It detects what
> is the best engine to use and creates a customisable interface based
> on that. So Safari gets the HTML5 uploader with the drag-and-drop,
> while IE falls back on a Flash uploader, etc. If you have GoogleGears
> installed, it will use that, too.

I'm rather against using a Flash fallback (constant causing Safari to hang when I allow it to play, killall -9 WebKitPluginHost gets used far too often), not to mention that your suggested fallback doesn't support drag and drop (assuming they at least keep that part of the table up to date).

Maybe you haven't released this, but Safari doesn't support the File API so will be given the Flash version.

Not to mention Apple is slowly fading Flash out from their new Macs (currently just the MacBook Air), so giving them a Flash fallback won't work either.

The current AssetAdmin has a completely functional HTML4-only file upload system that can be redesigned to look like it fits with the new upload design, just without those effects that most browsers don't support.

> It just seems to do all the work that I don't want to do when dealing
> with the varying support for uploading.
>
>
>
> On Mar 31, 3:21 am, Simon J Welsh <welsh.si...@gmail.com> wrote:
>> On 29/03/2011, at 5:19 PM, Felipe wrote:
>>
>>> *- Multiple file upload*
>>> *- html5 Drop to upload*, straight from your desktop to the cms
>>> *- Editing during upload*, while you wait the upload you can add title, tags
>>> etc
>>> *- Inserting multiple images at once*, as we moved from sidebar to modalbox
>>> that's necessary to avoid opening ang close the popup all the time
>>> *- Images from a url, *multiple urls with live preview
>>> *- Images from a Files manager, *aslo multiple files with search and browse
>>> functionality
>>
>> Can we get some designs for what file uploading will look like without the File API? Especially since most browsers don't support it.
>> ---
>> Simon Welsh
>> Admin ofhttp://simon.geek.nz/
>>
>> Who said Microsoft never created a bug-free program? The blue screen never, ever crashes!
>>
>> http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e
>

> --
> 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.
>

---
Simon Welsh
Admin of http://simon.geek.nz/

[Simon J Welsh]

On 1/04/2011, at 7:31 AM, Sigurd Magnusson wrote:

> What's the support that IE9 has in terms of drag and drop file uploads?

Non-existent.
---
Simon Welsh
Admin of http://simon.geek.nz/

[Uncle Cheese]

The current AssetAdmin is "fully functional," sure. But so is
Microsoft Access 97. The fact is, from a UI perspective, it's just not
good enough for a CMS built in 2011. SilverStripe 3.0 has to provide a
better uploading experience, and it can't afford to limit that
experience to a limited market.

I can't stand Flash as much as the next guy, but the fact is, right
now 95% of users can enjoy robust uploading with progress bars, file
type interrogation, multiple file selection and more. It seems
premature to me to make the decision to now punish 60% of users (non
FF4/Safari/Opera) who don't have HTML5 upload support by giving them
primitive HTML4 upload experience. I can't imagine installing a brand
new CMS that throws me an HTML4 uploader. I'd have a hard time taking
it seriously, and I'm pretty sure it would be a non-starter for most
users. Every CMS and web application I can think of provides a robust
uploading experience, albeit through Flash.

Flash is not the future, I agree. But we're not there yet, and I think
we need to accommodate the non-HTML5 users a little more thoughtfully.

On Mar 31, 2:44 pm, Simon J Welsh <welsh.si...@gmail.com> wrote:
> On 1/04/2011, at 3:40 AM, Uncle Cheese wrote:
>
> > You may already be aware of it, but I'd like to recommend Plupload

> >http://plupload.comas an HTML5/Flash upload wrapper. It detects what

> > For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.
>
> ---
> Simon Welsh

[Sam Minnée]

Flash has been a cause of many difficult-to-debug long-lived bugs in the past. From my perspective, there would need to be a strong reason to include it.

Does plupload support an easy way of enabling / disabling flash? If so, we could ensure that AssetAdmin works well without it, and have flash support be a configuration option. In particular, that makes 'disable flash' a quick fix if you run into stability problems.

[Hamish Friedlander]

Unfortunately plupload is under the GPL and is therefore license incompatible with SilverStripe - http://www.plupload.com/license.php.

Hamish Friedlander

SilverStripe

[Hamish Friedlander]

Sorry, that should be "is license incompatible with being included in SilverStripe core". You are of course allowed to use it in your own projects, you'd just have to distribute those projects under the terms of the GPL.

Hamish Friedlander

SilverStripe

[Uncle Cheese]

Bah.. You're right.

Well, ultimately, the exclusion of Flash uploading is just another
passive aggressive way of ushering users out of Internet Explorer, and
that's nothing new. I'm all for exploiting the flaws in a browser that
has never managed to live up to the standards of its time.



On Mar 31, 4:25 pm, Hamish Friedlander <ham...@silverstripe.com>
wrote:

[Richard Ward]

Yes, It is indeed easy to disable - just a case of missing out 'flash'
in the list of fallbacks you want it to use. But that's irrelevant as
Hamish points out. Shame.

On Mar 31, 8:58 pm, Sam Minnée <s...@silverstripe.com> wrote:
> Flash has been a cause of many difficult-to-debug long-lived bugs in the past. From my perspective, there would need to be a strong reason to include it.
>
> Does plupload support an easy way of enabling / disabling flash? If so, we could ensure that AssetAdmin works well without it, and have flash support be a configuration option. In particular, that makes 'disable flash' a quick fix if you run into stability problems.
>

> On 1/04/2011, at 8:17 AM, Uncle Cheese <aaroncarl...@gmail.com> wrote:
>
>
>
>
>
>
>
> > The current AssetAdmin is "fully functional," sure. But so is
> > Microsoft Access 97. The fact is, from a UI perspective, it's just not
> > good enough for a CMS built in 2011. SilverStripe 3.0 has to provide a
> > better uploading experience, and it can't afford to limit that
> > experience to a limited market.
>
> > I can't stand Flash as much as the next guy, but the fact is, right
> > now 95% of users can enjoy robust uploading with progress bars, file
> > type interrogation, multiple file selection and more. It seems
> > premature to me to make the decision to now punish 60% of users (non
> > FF4/Safari/Opera) who don't have HTML5 upload support by giving them
> > primitive HTML4 upload experience. I can't imagine installing a brand
> > new CMS that throws me an HTML4 uploader. I'd have a hard time taking
> > it seriously, and I'm pretty sure it would be a non-starter for most
> > users. Every CMS and web application I can think of provides a robust
> > uploading experience, albeit through Flash.
>
> > Flash is not the future, I agree. But we're not there yet, and I think
> > we need to accommodate the non-HTML5 users a little more thoughtfully.
>
> > On Mar 31, 2:44 pm, Simon J Welsh <welsh.si...@gmail.com> wrote:
> >> On 1/04/2011, at 3:40 AM, Uncle Cheese wrote:
>
> >>> You may already be aware of it, but I'd like to recommend Plupload

> >>>http://plupload.comasan HTML5/Flash upload wrapper. It detects what