I'm gonna use comments to post seperate screens so they can be commented on individually and because I like seeing my own picture so much…
- Tried to start from scratch and only add the things needed to get up and running.
- Using D7 core patterns as much as possible. Combining, extending, abusing where needed.
- Not to forget how much we can win by rewriting form field labels and descriptions: http://skitch.com/yoroy/dg8ii/copy
I didn't really deep-dive into round 1: http://groups.drupal.org/node/64143 so if there are parallels, maybe those are the likely better ideas :)
Comments
High-level concept: the object central, operations beside
Oh and this one
Regarding overrides
Overriding is a difficult concept. I see it as customizing a display. This is an idea for how to make that switch from 'use defaults' to 'custom setting'. Editing defaults themselves would only be done on the default display. Yes, an extra click, for more clarity on when if affects which display.
1. Taking it from the start: idyllic blank slate
Sadly i cannot access the
Sadly i cannot access the image.
This all sounds good beside:
Renamed 'default views' to 'templates' and tucked them away in a collapsible fieldset. They are not 'first thing'.'Code views' might be a alternative word.
I don't like the idea of moving them into a collapsible fieldset. if you really want to use views (my oppinion) you should export them into code (for example with features) module. Then you edit something via ui and then export it again.
So they are definitive a 'first thing'.
2. Template views? What are those?
3. Default view: couple of views created
4. Editing a single view
5. Edit a Display
Lets see if we can edit displays 'inline'.
A similar pattern might get in core for Fields UI, basically expanding a single row in a table:
- http://drupal.org/node/796658#comment-3038586
- http://drupal.org/node/796658#comment-3043192
6. Edit a display: filters
delete-configure
Suppose better "delete and configure" replace with test links at right
7. Edit a display: filters 2
Add
This "Add" is a submit under select
But "Add new filter" better at #6
8. More magic here…
…
And I'm not even showin a preview here. Lots of other stuff missing too but what you think so far?
And even more designs
Jeff at Acquia posted his thoughts on a simpler workflow model for composing views: http://www.flickr.com/photos/69716653@N00/sets/72157624486332877/
OMG, flickr makes it take
OMG, flickr makes it take like 4 clicks to see each photo, and then you have to remember which one you looked at last. :/
Well, as a pie in the sky
Well, as a pie in the sky design it's interesting. I have some problems:
1) That requires an icon for every style. History with Panels suggests that icons are a bit hard to come by for me. With Panels yoroy got me a great set of icons to get started...and even though I need 3x as many I still have...a great set if icons to get started. This isn't a knock on yoroy, it's just that I don't have the ability to create new icons, really, and therefore, they never get created. More than that, lots of styles are in other modules. They'd need icons too.
2) The drag & drop field editing is pretty sweet looking. Also currently well beyond my capabilities.
3) The checkbox for a block assumes your view will have only one block. Views ships with views with multiple blocks.
4) This starts with a page. In fact, it's some kind of interesting amalgam of Page Manager and Views that way. But what if your Views don't start with pages? I'm both intrigued and terrified by this, mind you, but because of the way Page Manager has been going I don't want to add more features to Views that are going to run parallel..
5) I assume a bunch of settings and stuff have been left off in an effort for this to be a more SimpleViews type of UI rather than really the main Views UI? If so...I'm not sure how useful it is to me. Do I have to write multiple UIs? Are we leaving site developers who depend on the 'advanced' stuff out in the cold? Do I have to maintain 2...3...4 different but similar UIs?
More: 6) Long edit field
More:
6) Long edit field forms will be a real drag, there will be a lot of scrolling and that fairly short form area could be a problem.
7) Dragging the fields in one at a time and configuring is interesting but it feels more difficult than the current workflow.
8) I'm really concerned about how this will degrade, i.e, function without javascript. Right now Views is usable without .js. I'd like to get more accessible and make it so that ezufelt can create views too, which means we need a workflow that can still function without relying completely on location for cues.
Sorry about the flickr thing....
Since the designs are Gardens related, it didn't seem right to post them here. Seems like you were able to get through it though. It is a little better if you view via the slideshow and have the slideshow expand to fill the monitor.
Responding to your feedback by number...
1. Yes, it will require an icon for things like fields vs nodes and tables vs lists, but this is isolated to gardens and we can add as needed. We can also contribute back and add new icons forwhatever is needed if the community decides to use this module too.
Thanks... we'll be coding the drag and drop stuff at Acquia. That is if we decide to see this design direction through.
Yes, one block view only. This is on purpose to keep things simple. If users want multiple blocks, the thinking is that people can further modify the simplified view via regular Views.
People create web pages, not web views. For this reason, I'm largely just pulling the wool over peoples eyes by calling the view a data page vs a view. The ability to select a layout is totally a concept at this point. Ultimately I think it makes sense to try to combine Views, Panels, Display Suite, and possibly Context into one UI. A seriously tall order, maybe too tall, but if we could be successful, it would be a game changer.
That's right, I'm leaving stuff out to keep things simple. The assumption is that Acquia will build and maintain this particular View UI add-on.
What's the longest field form? Interested to know. I think we have a solution though, not shown in this UI, but others we're doing here, you can expand the header/admin bar to consume 80% of the page.
I purposely wanted to avoid multiple fields at once. For power users I think the approach Views currently takes is helpful, but its overwhelming for beginners.
We worry less about degradation in Gardens. We're focused on the 80%. The 20% won't have a great experience, but the 80% will have a great experience.
I'm glad you took a look at the visuals. Thanks for the feedback. When I first started this exercise, I started rev'ing the actual Views UI. You might be interested in what I did there, so I'll post those shortly.
other views UI here
http://groups.drupal.org/node/83924
I continued/restarted
I continued/restarted conversation about Views 3 UI and these concepts at http://groups.drupal.org/node/90854
Bevan/