Ticket #9295 (closed PLIP: wontfix)
Improved UI for collections
Reported by: | elvix | Owned by: | elvix |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | Templates/CSS | Version: | |
Keywords: | Cc: | csenger, plip-advisories@… |
Description (last modified by elvix) (diff)
Proposer: Geir Bækholt
Seconder: Denys Mishunov
Motivation
Collections are one of the more powerful tools for content-editors in Plone. They are, however, in their current state, still very hard to use. This proposal is for using ajax/javascript to make a simpler, more sane and streamlined user experience for using collections.
Assumptions
This is under the assumption that #9283 is implemented. Building this UI on top of an Archetypes backend that will be removed anyways seems like a waste of work.
Proposal & Implementation
A simple interactive JS/AJAX-driven form where the user can add one line (i.e one clause to the query) at a time. Adding a clause/line will narrow the resultset immediately. If the user changes or adds criteria, the bottom area will update a tally of how many results are found immediately. — and also a preview list of the first few results.
Adding a line/clause/criteria will be a simple one-step process, not the current two step process where users first save their criteria type, then return to the form to fill data. The current form process is extremely confusing to users.
See attached screenshot for example of a way the criteria form can look.
The editing of criteria should happen in the main collections edit screen. — not on a separate tab. The fact that collections are 'nothing' before the user navigates to the "criteria" tab makes it hard for users to discover what collections are for.
Deliverables
Together with the implementation of #9283, implementation will primarily result in a new installable module, replacing the collections from ATCT. This will be implemented as a separate product that can be used regardless of whether it is included in the Plone core or not. I still hope that the FWT will keep the option open of including this improvement if the implementation is ready and tested in time.
Risks
The biggest risk is not having enough time for implementation and testing. The UI needs user-testing to find snags that would make it hard to use.
Participants
Implementation depends on #9283. Not trivial, but the Jarn-team will arrange one or two sprints for working on the search and collections related PLIPs. Key people ein the plone community has reacted very positively to this and promised to help out.. Laurence Rowe, Geir Bækholt, Denys Mishunov, Participants from 4digits and Netsight, Joel Burton
Progress
A lot of discussion has happened already. No code as of yet.
Attachments
Change History
Changed 7 years ago by elvix
-
attachment
Collections UI proposal.pdf
added
comment:1 Changed 7 years ago by MatthewWilkes
- Description modified (diff)
Hi Geir,
This appears to be a feature request, not a PLIP. Please reread http://plone.org/news/proposals-for-plone-4-solicited especially regarding the format for PLIPs.
Sorry, I'm being zero-tolerance on PLIPs not following the format :)
comment:2 Changed 7 years ago by elvix
Fair enough. I assume the pointer to "do it like this old plip" is the documentation you are referring to. I'll do that :)
comment:3 Changed 7 years ago by MatthewWilkes
Yeah, that's the fella! Oh for a system that enforced those fields, like wot we used to 'ave. *goes back to grumbling on #plone-framework*
comment:5 Changed 7 years ago by pupq
Yes! People are always confused by this in class!
Also, showing "how many results does this criteria alone find" would massively help with people's confusion about "which of my criteria is the one that causes nothing to be found". We probably all learn to "add them one a time and test", but, in watching thousands of students do this, very few of them do--and get very frustrated when they get no results, and can't figure out why.
Getting that as an option in your UI, Geir, would rock. (& let me know when you sprint on this; I would love to come and help).
comment:6 Changed 7 years ago by elvix
As a secondary proposal: i think that this UI should be used for advanced search as well. Will that need a separate PLIP?
comment:8 Changed 7 years ago by csenger
- Cc csenger added
- Description modified (diff)
There is also Sean's GSoC project (Folder UI impovements/faceted search) that gives an advanced UI for filtering content.
I'd love to see a really advanced solutions for finding content, but the trac like interface in this PLIP and the faceted search interface in Sean's Project are both too advanced to be the default for anonymous visitors. The way to go there is to simplify the interface at the cost of reducing the functionality, not the other way around, and give them more help and less to think about. So I'm against making this interface the default.
But both, your's and Sean's, may be the better solution depending on the user base. So I'm all for giving the administrator an option to select them for either anonymous or authenticated users, and maybe an option for the users to change it in their preferences.
The implementation for a search with this interface is more tricky, as the interface is very flexibel and there is no collection object around that does the work depending. Either one has to cheet (we're still in Archetypes land) or implement a backend that replicates the functionality without persisting it.
Surprisingly we have at least 3 project's around that start to deal with a flexible UI to configure forms/searches:
- This one
- Sean's project
- Quyết Nguyễn Đức's GSoC project (PloneFormGen improvements, mentor Steve McMahon, no URL)
Maybe there can be some shared UI/javascript code.
comment:9 Changed 7 years ago by elvix
- Description modified (diff)
update the description to be properly in line with the new formatting guideline.
comment:10 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:12 Changed 7 years ago by MatthewWilkes
I'm not sure how this will relate to #9283 - I'm guessing your new implementation will be the only recipient of this UI? I'm not sure why these PLIPs are separate.
That said, this is a clear win.
FWT Vote: +1
comment:13 Changed 7 years ago by rossp
I *really* want to see this happen, I just don't think it belongs in core when its a perfect candidate for creating an add-on to vet it. Maybe this is a candidate for 4.x once vetted as an add-on? FWT vote -1.
comment:14 Changed 7 years ago by davisagli
FWT vote: +1
comment:15 Changed 7 years ago by raphael
FWT vote -1 when it comes to Plone 4.0 for the same reasons as #9283
comment:16 Changed 7 years ago by calvinhp
FWT Vote: +1 can this be combined with your dependant PLIP for review?
comment:17 Changed 7 years ago by erikrose
Yes, please! :-D I rarely hit Plone from a user point of view, so when I used Collections heavily while writing a recent Plone in Education chapter, I couldn't believe how bad the UI was. I truly don't think we can do any worse, so I'm all about including this in the canonical distribution unless the implementation totally falls flat (which I have no reason to expect).
I like the previewing, but I LOVE the fast-feedback client-side UI. In the current UI, one never knows which submit button to click. I also dig unburying the post-creation steps from the Criteria tab. Better still, can we get the criteria editor to show up before object instantiation?
FWT vote: +1
comment:18 Changed 7 years ago by esteele
Approved by FWT vote.
comment:21 Changed 7 years ago by elvix
comment:22 Changed 7 years ago by esteele
Looks great!
Comments from a quick look:
- It appears that the "state" option doesn't work properly
- The modifier dropdowns should default to the inclusive option ie "equals" before "does not equal"
- The text fields might use "contains" and "does not contain" modifiers since they're not searching for matches of the full text
comment:23 Changed 7 years ago by elvix
All these three issues stem from the config data, not from errors in the code. There are still improvements being made to this data and its storage. We have been awaiting the FWT's judgement on whether we can depend on plone.registry in order to move it there.
comment:24 Changed 7 years ago by jaroel
I'm currently working on that. Dynamic configuration based on the actual catalog indexes as a temporary solution. When plone.registry is allowed, I'll rewrite to use that.
comment:25 Changed 7 years ago by xela7
fun to filter quickly. 'equals' appears to be the same as 'does not equal'. At one point, the item type select menu got stuck ontop of a later criteria. To get fix I had to delete all criteria. In the above mockup there is an "and" written -- no such 'and' to be found on the actual collection page. This could be a good clarification for end users.
Changed 7 years ago by xela7
-
attachment
collections bug.png
added
this is a bug I have seen on firefox 3 for mac 10.5.7
comment:26 Changed 7 years ago by xela7
I just attached a screenshot (collections bug.png) -- I think I get this by adding criteria, then viewing, then trying to edit again.
comment:27 Changed 7 years ago by erikrose
comment:28 Changed 7 years ago by erikrose
comment:29 Changed 7 years ago by alecm
comment:30 Changed 7 years ago by cjohansen
Results of testing with FAE ( http://fae.cita.uiuc.edu/) were slightly lower than Plone baseline results. More failures and warnings associated with missing h1 element. Not a significant barrier to screen readers, but should be fixed eventually.
comment:31 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 23.
comment:32 Changed 6 years ago by rossp
FWT vote: -1 for merge
comment:33 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to wontfix
Based on FWT response of the current state of this PLIP, I'm closing it for 4.0. I'd very much like to see this revisited in a 4.x release.
comment:34 Changed 6 years ago by limi
- Priority changed from minor to n/a
- Milestone changed from 4.0 to 4.1
Moving to 4.1 at Geir's request.
comment:35 Changed 6 years ago by limi
- Status changed from closed to reopened
- Resolution wontfix deleted
comment:36 Changed 6 years ago by hannosch
- Priority changed from n/a to minor
- Component changed from Unknown to Templates/CSS
comment:37 Changed 6 years ago by elvix
- Status changed from reopened to closed
- Resolution set to wontfix
This PLIP is superceded by #10902
Proposed query form