Gridfield / ModelAdmin proposal - lets make it more usable.

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Everyone

I would like to propose that we include: https://github.com/unclecheese/silverstripe-gridfield-betterbuttons/ into the SS core ASAP (or something along those lines). 

All I have done is to have a quick look at the README file for this module - but from that, I can only say "YES PLEASE".  

Anyone who has tried to enter anything into a ModelAdmin Gridfield in SS3.0 knows that there is a lot of room for improvement.  It is simply too slow, cumbersome and unintuitive.

Yes, the core concepts and development setup of SS is wonderful, but from a user (content editor) point of view it is not exactly "award winning".  I recently had a student helping me with some data entry for a site and I had to apologise several times for the slowness of the "system".  

What do you think?

Nicolaas

[kinglozzer]

I'm somewhat against it being added to the core. There are times when, for example, the 'prev/last' arrows (and therefore 'save & go to next/last record') are simply not necessary/logical - so you'd need a load of extra configuration (i.e. adding/removing components from the GridFieldConfig or something) to enable and disable certain features of it. You'd end up with two scenarios:

• Everything already added, devs then have to configure the removal of each button they don't need
  
• Nothing added, devs have to add each feature they want

Either way, in my opinion it probably works better as it is - packaged up as a module - given how easy it is to install with composer. The 'Save & Close' action would be a nice addition to the core but again it's so easy to put into a module and install anyway.

[Ingo Schommer]

I'm in favour of adding "Save & Close" as well as "Save & Add New", 

they're really useful to pretty much all users (not only power users).

Not sure about the "Save & Next" etc, particularly if it necessitates yet

another custom UI element we have to maintain (button+dropdown).

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

[Will Rossiter]

The delete button enhancements would be useful to include in core as well IMHO.

[Nicolaas Thiemen Francken - Sunny Side Up]

I think the key thought for me is the following;

Right now, to edit a list in the default gridfield is slow, clumsy and cumbersome.  Despite the great concept and excellent structures. 

Either we have a solid GridField in the core or not at all. 

Or put it another way - do we really need to repeat history where everyone adds DataObject Manager to make the CMS usable? (I dont see it that way - but I know a lot of people would not never install SS without DataObject Manager)

Lots of people are building really cool extensions, but I think some of them should go into the core.

What we all want is a GridField that is

* intuitive

* fast

* ready to go without having to add some additional module

How can I help to make it happen?

Nicolaas

[Ingo Schommer]

On 22/05/2013, at 11:24 AM, Nicolaas Thiemen Francken - Sunny Side Up <ma...@sunnysideup.co.nz> wrote:

> Either we have a solid GridField in the core or not at all.

While I agree in principle on this GridField UI, I think we need to get away from the idea of "most people use it, so it needs to be in core".
The core team is simply too small to maintain all of these variations. I don't have a problem with a thriving ecosystem of modules
around GridField, and rather focus on making them easy to install (composer), easy to write+use (GridField core API),
and easy to discover (new addons.ss.org).

> How can I help to make it happen?

By adding test coverage to that module.

Ingo

[Nicolaas Thiemen Francken - Sunny Side Up]

On 22 May 2013 22:03, Ingo Schommer <in...@silverstripe.com> wrote:

On 22/05/2013, at 11:24 AM, Nicolaas Thiemen Francken - Sunny Side Up <ma...@sunnysideup.co.nz> wrote:

> Either we have a solid GridField in the core or not at all.

While I agree in principle on this GridField UI, I think we need to get away from the idea of "most people use it, so it needs to be in core".
The core team is simply too small to maintain all of these variations. I don't have a problem with a thriving ecosystem of modules
around GridField, and rather focus on making them easy to install (composer), easy to write+use (GridField core API),
and easy to discover (new addons.ss.org).

That makes sense ...  

I guess the key here is the half-baked solution  Perhaps we can carefully select a few "easy wins" that we can all agree on.  Which dont add much "weight" or extra work, but create the most basic grid field that is complete and impressive. 

I totally agree with getting away from the imperative of "most people use it".  However, in this case it is more fundamental. The core functionality of a CMS is to edit content and when its most fundamental field, i.e. the Grid Field, is half-baked then something is not right. 

Think about it from the perspective of a developer who is new to Silvestripe.  They install, add a data object ... wow this is easy .... then comes modeladmin - even more impressive .... and then they look at the Grid Field... They are not going to be impressed. Either you leave it out - and the developer is forced to explore "plug-in" modules for an editor.  Or we provide a smart editor for the most basic of situations: editing a list of data objects. 

Would it be an idea to start with a list of easy-win improvements (or a list of things that are currently not working so well) for the Grid Field that we can all agree on?  Maybe just five small improvements that make for a solid Grid Field. 

Nicolaas

PS 

I just stumbled upon this one too:

https://github.com/ajshort/silverstripe-gridfieldextensions

 

[Uncle Cheese]

Wow, glad to see this module is getting some attention. I whipped it up really quickly one afternoon when my tedium with the GridField workflow had reached its peak. It has a long way to go. There are a number of major DRY violations because GridFieldItemRequest is not that decoratable. That would be an easy core update, though.

The biggest issue with the module right now is that the previous/next functionality is not orthogonal. If you sort or filter the grid, the adjacent records are not accurate in the detail view. As far as I can tell, there is no way to get that information from the edit view of GridField.

While "save and go to previous" is a bit of a stretch, I think "save and next" is extremely useful when doing bulk updates, e.g. having added a new field and populating it across all records. If adding and removing buttons is really desirable, I think a simple entry in the _config layer is all you would need. I think that level of configuration is expected with modules now.

Nicolaas brings up a great point about DOM, so let's remember the lessons learned from that endeavor. Yes, it made the CMS more usable, but at what cost? It was a monolithic beast that contained every feature under the sun, and it was impossibly opaque and inextensible. Meanwhile, the whole thing had a single point of maintenance and development, so when Uncle Cheese got tired of closing tickets, it simply decayed.

On the other hand, if we look at GridField as being just the opposite -- divergent, decoupled, and fed by an ecosystem of plugins, maybe that's a more forward-thinking, sustainable solution. The introduction of Composer has really been a game-changer in the "everyone uses it" problem.

[Nicolaas Thiemen Francken - Sunny Side Up]

Here is what I would suggest we add to the core (DRAFT ONLY - ANY INPUT WELCOME)

1. previous and next record buttons

• WHY: it significantly reduces the clicks (halfs them!) when browsing / editing any data list. 
• HOW: anytime a list is displayed in GridField, we safe a list of IDs in session - when we open one record, the next and previous are dictated by this session list of IDs.

2. clean up buttons in list view: 

[ADD MY OBJECT] 

[PRINT] [EXPORT]

• WHY: they take up far too much prime real estate.
• HOW: move export + print buttons to the bottom of the view

3. whenever a record is saved, we show a few "what would you like to do next?" options.  These options include:

• BACK to list
• Add new record

• WHY: takes a lot of time to add just a few records because of the need to keep returning to the list before adding another item.  

4. in the edit view - move delete away from save and add a "are you sure"?

• WHY: add and delete are too close together - may click the wrong button - when you do there is no undo and it is too late. 
• HOW: add should go to the bottom-left to follow the natural flow for left-to-right top-to-bottom readers.

5. Clean up some of the labels and concepts in the Import form:

• WHY: not usable in its current state due to confusing labels and lack of information
• HOW: change "Clear Database before import" to something like "add to existing data" (the opposite) OR "remove old ... first" where ... is the name of the dataobject (e.g. countries / employees).
• Add example CSV that can be downloaded

Have to run now, but if there is support for something like this then we upcoming hackfest can perhaps be used to make it happen.

Nicolaas

[kinglozzer]

1. previous and next record buttons

• WHY: it significantly reduces the clicks (halfs them!) when browsing / editing any data list. 
• HOW: anytime a list is displayed in GridField, we safe a list of IDs in session - when we open one record, the next and previous are dictated by this session list of IDs.

I'm happy with this as long as they can be removable/hide-able - there are occasions that I use the GridField for items where such buttons wouldn't make any sense. I guess you could argue that I'm using the GridField incorrectly though ;).

 

2. clean up buttons in list view: 

[ADD MY OBJECT] 

[PRINT] [EXPORT]

• WHY: they take up far too much prime real estate.
• HOW: move export + print buttons to the bottom of the view

Makes sense. We could just float the 'export' + 'print' buttons right and have them on the same line as the 'Add new' button?

 

3. whenever a record is saved, we show a few "what would you like to do next?" options.  These options include:

• BACK to list
• Add new record

• WHY: takes a lot of time to add just a few records because of the need to keep returning to the list before adding another item.

Not sure about this one. We may as well just have 'save' and 'save & close' buttons. That example would have two clicks for both actions, whereas having the two buttons instead would mean one click for 'save and close' and still only two clicks for 'add new record'.

 

4. in the edit view - move delete away from save and add a "are you sure"?

• WHY: add and delete are too close together - may click the wrong button - when you do there is no undo and it is too late. 
• HOW: add should go to the bottom-left to follow the natural flow for left-to-right top-to-bottom readers.

100% agree with this one, especially the delete confirmation. How it hasn't been added before now I don't know!

5. Clean up some of the labels and concepts in the Import form:

• WHY: not usable in its current state due to confusing labels and lack of information
• HOW: change "Clear Database before import" to something like "add to existing data" (the opposite) OR "remove old ... first" where ... is the name of the dataobject (e.g. countries / employees).
• Add example CSV that can be downloaded

Yes to this. The "specification" is a bit confusing at the moment, as by default it just lists each field name twice (one is supposed to be a description). Shouldn't be shown a second time if no description is present. 

[Uncle Cheese]

>>>Not sure about this one. We may as well just have 'save' and 'save & close' buttons. That example would have two clicks for both actions, whereas having the >>> two buttons instead would mean one click for 'save and close' and still only two clicks for 'add new record'.

There's a BIG difference between a click that happens on a totally new screen, and a click that happens on the same screen, within close proximity of the previous click. They're both two clicks, but one is much more pleasant than the other.

[Nicolaas Thiemen Francken - Sunny Side Up]

On 24 May 2013 09:08, Uncle Cheese <aaronc...@gmail.com> wrote:

>>>Not sure about this one. We may as well just have 'save' and 'save & close' buttons. That example would have two clicks for both actions, whereas having the >>> two buttons instead would mean one click for 'save and close' and still only two clicks for 'add new record'.

There's a BIG difference between a click that happens on a totally new screen, and a click that happens on the same screen, within close proximity of the previous click. They're both two clicks, but one is much more pleasant than the other.

Hi Uncle

What you are saying is that having a click in a familiar surrounding close to the last click is better?  

Sorry, just double-checking what may be completely obvious 

[Tony Air]

let's also add blocks view for objects that has one photo.

--

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

--
Best regards, Tony Air
CEO, The Web Development Agency (New Castle LLC)

E-mail: to...@thewebdevelopmentagency.ru
Skype: a2nt.fd
Mob. +7 (923) 136-60-13 (OVB)
Mob. +7 (967) 004-08-17 (DME,SVO,VKO)
http://TheWebDevelopmentAgency.ru/

[Paul Clarke]

My 2 cents

@Tony, It has always been the intention to eventually have a grid view for images and it is about time we revisited that, thanks for bringing it up.

Grid field buttons - I think "save and add new" wold be useful, but I think the "save" button and "save and close" are double ups. I'm not that sure about "save and go to next/previous record", it saves one click but adds a little more clutter. Sometimes the more options a user has the more complex their experience is even if you are providing lots of short cuts for them to use.

Attaching a mockup which is closer to the way things are currently implemented.

[Paul Clarke]

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Paul

I did not see any attachments.

Also, I agree with you... You just want a save button - nothing complex with "save and think for five minutes what you want after that" 

HOWEVER - the way it works at the moment is unacceptable to my clients.

Just try adding five records using Model Admin

Just try editing five records using Model Admin

And make sure you are on a $5.00 hosting plan with Go Daddy ... just to know what it is like for most Silverstripe users. 

Apart from layout and action changes, another way to improve the experience is to Ajax PreLoad the next step... A bit like going through a photo album - the prev and next photo are already downloaded by the user to increase the speed. So that when you click on previous and next, it is just a quick "hide" and "show" in JS - nothing more. 

There is a small chance I am able to come to the hackfest tomorrow and see if I can put together some examples of an improved GridField. 

Nicolaas

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

--
Nicolaas Thiemen Francken  

Sunny Side Up Ltd  {
  Skype: atyourservicehour
  Phone: +64 4 889 2773 

  Emergencies: 0221697577
  n...@sunnysideup.co.nz
  http://www.sunnysideup.co.nz

}

[Nicolaas Thiemen Francken - Sunny Side Up]

sorry, image found.

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi Paul

A couple of notes in response to your design - looking great. 

Save button should go on the left-hand-side: for people who read from top-left to bottom-right ..... The save button is outside of the natural flow.  This is a pain. Why not put the Save button bottom-right. Bottom-left is the sort of place you put "delete". 

One other thing we could consider is, for example, if you do save and "add new", then this becomes your default option... Because if we use the design as you attached, then save and go next is still tricky.... having a drop-up requires a lot more brainpower then just a button... Hope that makes sense. 

Nicolaas

[kinglozzer]

Paul, in my opinion that design is our solution - I'd forgotten about the popup action menus. It adds all the buttons people are asking for, but without cluttering up the actions bar (which was personally my main concern). 

Save button should go on the left-hand-side: for people who read from top-left to bottom-right ..... The save button is outside of the natural flow.  This is a pain. Why not put the Save button bottom-right. Bottom-left is the sort of place you put "delete". 

Did you mean "save button should go on the right-hand-side"? I think if that change is made, then it opens a can of worms - the action buttons for the SiteTree have to be refactored as well, as would the "Add new {DataObject}" button above the GridField.

 

One other thing we could consider is, for example, if you do save and "add new", then this becomes your default option... Because if we use the design as you attached, then save and go next is still tricky.... having a drop-up requires a lot more brainpower then just a button... Hope that makes sense.

I agree with the point that the extra actions would still be a little 'out of the way'. I'd suggest hoverintent here to remove the extra click (it seems to be still included, despite not being used anywhere) unless anyone has a better solution.

[Nicolaas Thiemen Francken - Sunny Side Up]

On 24 May 2013 20:57, kinglozzer <kingl...@gmail.com> wrote:

Paul, in my opinion that design is our solution - I'd forgotten about the popup action menus. It adds all the buttons people are asking for, but without cluttering up the actions bar (which was personally my main concern). 

Save button should go on the left-hand-side: for people who read from top-left to bottom-right ..... The save button is outside of the natural flow.  This is a pain. Why not put the Save button bottom-right. Bottom-left is the sort of place you put "delete". 

Did you mean "save button should go on the right-hand-side"?

YES - SORRY

 

I think if that change is made, then it opens a can of worms - the action buttons for the SiteTree have to be refactored as well, as would the "Add new {DataObject}" button above the GridField.

No, add new DataObject is top-left... that is fine... the main button on the bottom should be bottom-right. 

 

 

One other thing we could consider is, for example, if you do save and "add new", then this becomes your default option... Because if we use the design as you attached, then save and go next is still tricky.... having a drop-up requires a lot more brainpower then just a button... Hope that makes sense.

I agree with the point that the extra actions would still be a little 'out of the way'. I'd suggest hoverintent here to remove the extra click (it seems to be still included, despite not being used anywhere) unless anyone has a better solution.

I like the idea of remembering the last choice and make that default. 

[Sam Minnée]

On Thursday, 23 May 2013 00:02:00 UTC+12, Uncle Cheese wrote:

Wow, glad to see this module is getting some attention. I whipped it up really quickly one afternoon when my tedium with the GridField workflow had reached its peak. It has a long way to go. There are a number of major DRY violations because GridFieldItemRequest is not that decoratable. That would be an easy core update, though. 

The biggest issue with the module right now is that the previous/next functionality is not orthogonal. If you sort or filter the grid, the adjacent records are not accurate in the detail view. As far as I can tell, there is no way to get that information from the edit view of GridField.

While "save and go to previous" is a bit of a stretch, I think "save and next" is extremely useful when doing bulk updates, e.g. having added a new field and populating it across all records. If adding and removing buttons is really desirable, I think a simple entry in the _config layer is all you would need. I think that level of configuration is expected with modules now.

Nicolaas brings up a great point about DOM, so let's remember the lessons learned from that endeavor. Yes, it made the CMS more usable, but at what cost? It was a monolithic beast that contained every feature under the sun, and it was impossibly opaque and inextensible. Meanwhile, the whole thing had a single point of maintenance and development, so when Uncle Cheese got tired of closing tickets, it simply decayed.

On the other hand, if we look at GridField as being just the opposite -- divergent, decoupled, and fed by an ecosystem of plugins, maybe that's a more forward-thinking, sustainable solution. The introduction of Composer has really been a game-changer in the "everyone uses it" problem.

Just had an IRL chat with Nicolaas about this, thought it might be appropriate to give my 2c:

 - GridField was definitely designed to be a decoupled systems where people could combine a collection of components to meet their needs.  It's likely -- and healthy -- that developers of applications find themselves frequently adding additional modules of GridField components and our goal is to ensure that our module management tools make that straightforward.

 - The default components bundled with silverstripe/framework should probably be limited to those needed to power the default ModelAdmin scaffolds, as well as AssetAdmin, SecurityAdmin.  So the question of whether to bundle a component becomes "should that be part of our default ModelAdmin scaffold"

 - I agree with Ingo and Paul that replacing "Save" with "Save & Close" and "Save & Add New" is something we should do in core.

 - "Save & Next", "Save & Prev" or a "Save" button alongside "Next" & "Prev" buttons are something that make sense in more data-heavy applications targeted at power users and should be installable with a module, but not included in core.  However, I think we should introduce the following core refactorings to make this less awkward:

   - The GridFieldConfigs used for scaffolding has_many and many_many should be able to be customised, either across the board, on a specific data type, or on a specific ModelAdmin.  In principle, this would mean that you could get these extra features by doing nothing other than installing a module.

   - As Uncle Cheese aluded to, GridFieldDetailForm should have some mechanism for adding additional buttons.

Responding to a more specific point of Aarons': "The biggest issue with the module right now is that the previous/next functionality is not orthogonal. If you sort or filter the grid, the adjacent records are not accurate in the detail view. As far as I can tell, there is no way to get that information from the edit view of GridField."

--> You should be fine if you include your component *after* the filter/sort components.  Having looked at your code, it seems like there may be a bug in the relevant part of core.

With the release candidate of 3.1 just around the corner, I think that all of this is best left for 3.2 (i.e., master).  But let's aim to make things better for that release!  (Gallery view, too.   Zauberfisch: any update?)

[colymba]

I would agree that adding too many buttons is overkill and I like the fact that I can just customize Gridfield to whatever needs the app request. Having to remove a lot of default features seems to me a bit cumbersome.

Save+Close and Save+New might be useful in most case usage?

Like mentioned, the best would be to have GridFieldDetailForm easily extensible making adding new buttons or features easier.

If anyone is interested, I had a crack at a gallery view a little while ago: https://github.com/colymba/GridFieldGalleryTheme