All views in Drupal admin pages require a set of tools that are presented to the user with a consistent visual style and page architecture.
The tools should include
- actions, (usually, but not always, adding a new item)
- filtering
- sorting
- searching
- (filtering on a keyword using an autocomplete text field)
- paging
- bulk operations.
Since all of these things are tools to manipulate a view, they should be designed as a single toolset so we can improve discoverability, reduce anti-patterns and increase user efficiency.
This issue is a "meta, meta" issue since it references other meta issues. Not sure what the implications of that are but there it is.
The following prototype shows the functionality http://invis.io/R8F4K2BC
And here is a partial overview design of tables with the unified interaction pattern applied and anti-patterns removed
Comments
Comment #0.0
tkoleary CreditAttribution: tkoleary commentedAdded links
Comment #0.1
tkoleary CreditAttribution: tkoleary commentedlinked links
Comment #0.2
tkoleary CreditAttribution: tkoleary commentedrelinked
Comment #0.3
tkoleary CreditAttribution: tkoleary commentedremoved duplicate descriptions
Comment #0.4
tkoleary CreditAttribution: tkoleary commentedadded 1475204
Comment #0.5
tkoleary CreditAttribution: tkoleary commentedadded 1910896
Comment #0.6
tkoleary CreditAttribution: tkoleary commentedadded image caption
Comment #0.7
tkoleary CreditAttribution: tkoleary commentedimage
Comment #0.8
tkoleary CreditAttribution: tkoleary commentedimage
Comment #3
tkoleary CreditAttribution: tkoleary commentedComment #3.0
tkoleary CreditAttribution: tkoleary commentededitied
Comment #3.1
tkoleary CreditAttribution: tkoleary commentededited image
Comment #3.2
tkoleary CreditAttribution: tkoleary commentedadded linked issue https://drupal.org/node/2023683
Comment #3.3
tkoleary CreditAttribution: tkoleary commentedadded 2005166
Comment #3.4
tkoleary CreditAttribution: tkoleary commentedadded 2022297
Comment #4
tim.plunkettI have to say, swapping the sides of the operations and VBO checkboxes is one of the most disorienting things I've ever seen in a view.
Otherwise, I think it looks great.
Comment #5
gddI completely agree with tim. Checkboxes on the left is a standard used through pretty much every web app I could find which has a listing where individual rows can be selected (most notably email apps but also in others.) Swap that an operations back and I've got nothing bad to say.
I was following Bojhan on that. I was under the impression that it had been changed in another issue. I personally prefer them (bulk) on the left as well.
Comment #6
cweagans+1 for swapping the operations and checkboxes back. That's really disorienting.
Comment #7
dawehnerSo #1210980: Allow more options (above/below/both) for pager placement is one part we need.
Comment #8
tkoleary CreditAttribution: tkoleary commented@dawehner
Linking in the description.
BTW my base for this was work we did at Bad Camp.
Comment #8.0
tkoleary CreditAttribution: tkoleary commentedadded 1823608
Comment #8.1
tkoleary CreditAttribution: tkoleary commentedadded #1210980: Move pager above the page
Comment #9
tkoleary CreditAttribution: tkoleary commentedComment #9.0
tkoleary CreditAttribution: tkoleary commentedremoved #1210980: Move pager above the page (issue linked to itself!)
Comment #10
tkoleary CreditAttribution: tkoleary commented@heyrocker @cweagans @dawehner @tim.plunkett
Updated description image with operations swapped to current position.
Comment #11
tkoleary CreditAttribution: tkoleary commentedOne thing to note. The Pinterest style image grid in the grid view in files offers a great advantage to the user in that for images or videos with a variety of aspect ratios no part of the image is cropped, while a consistent look is also maintained.
This effect would require masonry.js. I am *not* suggesting that we add another library dependency to core. The reason I show it is that I think it's important to write the markup in such a way that plugging something like Masonry into the grid view is simple for someone creating an alternate admin theme or a module that leverages core admin views.
Related to #1903746: Replace the views grid table template with one using divs
Comment #12
klonos...adding #2020449: Provide a generic/reusable widget for configuring the number of displayed items per page in admin views listings. to the issue summary.
Comment #12.0
klonosupdated image
Comment #13
tkoleary CreditAttribution: tkoleary commented@klonos
Right! Missed that. Adding to the designs.
Comment #14
tkoleary CreditAttribution: tkoleary commentedTagging with theme component library per Jenlampton
Comment #15
LewisNyman CreditAttribution: LewisNyman commentedWe will need to consolidate these designs into the Seven styleguide
Comment #16
tkoleary CreditAttribution: tkoleary commented@LewisNyman
Right. I pulled from the existing work to put this together but there are a couple of new patterns as well as the overall layout.
I think what's new is:
The last three seem like they should be issues for media module though, and theme agnostic.
What do you think?
Comment #17
LewisNyman CreditAttribution: LewisNyman commentedWe haven't had a chance to discuss the future of the Seven style guide beyond this initial implementation but the intention was to have the style guide become a constantly evolving resource of administrative components. After this initial phase the plan is to add more components in order to consolidate patterns found in contrib. I think anything that affects the administrative interface should be placed within the Seven style guide, we don't want these UI patterns to carry into front end themes.
Everything I see here fits really well with this vision, I think it completely belongs under the style guide initiative.
Comment #17.0
LewisNyman CreditAttribution: LewisNyman commented...adding #2020449
Comment #18
klonosComment #19
LewisNyman CreditAttribution: LewisNyman commentedComment #20
tkoleary CreditAttribution: tkoleary commentedBoth filters and actions could probably use select 2 and in doing so be much more compact, efficient and usable.
Comment #25
giorgio79 CreditAttribution: giorgio79 commentedMaybe 8.6?
Comment #26
joachim CreditAttribution: joachim commentedI think this is a major, and I also think it's going to need way more work before it's ready.
Also, recent comments have been focussing too much on theme and front-end. The issue summary seems to be suggesting we build a new type of thing in Views to automatically get the same set of sorts, filters, bulk ops, and so on.
> Since all of these things are tools to manipulate a view, they should be designed as a single toolset so we can improve discoverability, reduce anti-patterns and increase user efficiency.
That to me is not just about theming. It's suggesting that when you build a view, you get an option for a standard set of sorts + filters + bulk ops, and that is something that's defined in one single place.
It's a very interesting idea, but it would be a LOT of work to add this to Views. For one thing, what looks like the 'same' sort or filter is actually a completely different thing for each entity type, so there'd be a new abstraction layer involved.
Comment #28
dqddeleted... Ooops .. wrong issue. My points better fit into this one: #1823450: [Meta] Convert core listings to Views