This is the second part of a series revealing the output of the part 1. One change to part 1 that's not shown in the designs is you can Save - which takes the user back to the list of views with a confirm (just like simple views), or Continue, which would take you into these designs to allow the user to further tweak the View.

All the designs are annotated, hopefully the annotations will speak for themselves. They're only partially in sequential order.

These settings are important, because they reveal how Views can be configured to work just like it does today:



Next we dive into the result of the designs in part 1 (assuming the user clicked continue on the create screen)







CommentFileSizeAuthor
11_Override_applied.gif61.58 KBNoyz
10_Add_displays.gif45.89 KBNoyz
9_Cofigure_first_filter_-_not_exposed.gif46.06 KBNoyz
8_Add_filters.gif47.65 KBNoyz
7_Page_showing_add_from_gears.gif55.77 KBNoyz
6_Page_with_advanced_options.gif69.42 KBNoyz
5_Page.gif72.08 KBNoyz
4_result.gif66.4 KBNoyz
3_Performance_Settings.gif52.08 KBNoyz
2_Default_Settings.gif30.89 KBNoyz
1_Display_Settings.gif27.06 KBNoyz

Comments

AdrianB’s picture

AdrianB commented

This looks good! And I like the renaming of Arguments to Dynamic filters.

dawehner’s picture

dawehner
Primary language German
commented

Some questions/comments:

* Empty text isn't a area anymore?
* It should exist a place to input the arguments for the preview
* The search textfield in the add "field/filter..." is awesome
* When the overlay module is not enabled, are all the configuration overlays replaced by the current behaviour?

ethnovode’s picture

ethnovode commented

Awesome ! I like everything, especially : intelligent add/edit overlay and the new sections order. It looks easier/faster to do what we need.

Thanks.

Anonymous’s picture

Anonymous (not verified) commented

Great job guys!

Greeting!

demeester_roel’s picture

demeester_roel commented

Great improvements!!

some remarks...

In 5_Page.gif
Is there a reason why the gear for changing settings on "Filters" is blue + right outlined
while the ones for title, header etc.. is gray and left aligned?

In 4_result.gif ..
There is bullet 3. "Save" only visible when view dirty....
Shouldn't that be "Save" only *enabled* when view dirty ?

Can't wait to actually use this new interface.

tsvenson’s picture

tsvenson commented

Fantastic work guys, really like all the changes and can't wait to try them out.

dmitrig01’s picture

dmitrig01 commented

I think this looks quite good. The one comment I had was where's the default display, and what if I wanted to create a view with only a default display.

ksenzee’s picture

ksenzee
she/her
commented

@dereine: The "overlay" would be a modal dialog created via ctools or jQuery UI, not an overlay.module overlay. It should work fine with or without overlay module enabled. I'm guessing the no-JS fallback would be the current behavior where the form is below the query editing area.

@dmitrig01: I think the answer is note #1 on mockup #4. If you created a view with only the default display, the default display would show up so you can edit it. You could also tweak your settings to always show default displays.

merlinofchaos’s picture

merlinofchaos commented

In these mocks, we're calling the 'default' display the 'master' display. By default (heh) it will only be visible if there are no other displays. However, there is a checkbox on the advanced settings page that will make it always visible, thus retaining the behavior we have today.

I think I like this because the default display is very powerful for experienced users and very confusing for new users. The one downside is that I worry that some newer users may never learn how it actually works.

Fannon’s picture

Fannon commented

Wow, this looks great to me !
This is a great direction Views is heading!

hongpong’s picture

hongpong commented

In the #2 defaults it seemed like those checkoffs could use more help info - they look cryptic right now. Not sure if this is germane :) Good work!

davyvdb’s picture

davyvdb commented

What comes in column 1 / 2 / 3 (or is this number flexible) of the "view builder" page?

In 5_Page.gif you have in column 1 stuff like "title", "sort criteria", "filters", ... but these are in no way related. Probably the most used stuff is in column 1?

I would love to see "related" stuff together. I see 4 main areas/stages in building a view:
- Select what data is in the view (filters, fields, sort, dynamic filters, ...) = adding dynamic data
- Build the view (header, footer, title, empty text, pager, ...) = adding more static data (pager is an edge case here)
- Selecting style (but this could be together with part 2 = how does it look / how does it come out (format)
- Change behavior and internals (ajax, caching, ...) = how does my view behave?

Fannon’s picture

Fannon commented

Suggestion: How about introducing a "default sort criteria" or some presets for this?

Otherwise you need to klick a lot, to be sure, that the (node) is published, sticky, sorted by date descending
Also i think that "descending" should be the first and default order, this is what i use 99% of the time.

Or is this misplaced in this thread?

Greets,
Simon

bojanz’s picture

bojanz commented

This is awesome, and I'm incredibly excited about it.
I like how the interface adjusts to various selected options, instead of showing everything in all cases.

A mockup is usually a starting point on which the developers build on, but this one is pretty solid as a whole, requiring more refinements than major changes.

I like the "master" display rename.

There is bullet 3. "Save" only visible when view dirty....
Shouldn't that be "Save" only *enabled* when view dirty ?

Definitely agree with this, the Save button should never be hidden, only disabled.

About the arguments => "dynamic filters" rename, "dynamic filters" is probably closer to telling what it is, "arguments" is a very opaque to new users.
Still arguments could use some work to make it more filter-like (why can't I select the operator for string arguments?), but that's another issue completely.

Noyz’s picture

Noyz commented

Answers to above questions.

#2.
A. Empty text is an oversite. With Page header and Page footer, i assume Empty Text is a lonely step child. I would see this as either and advanced option (not that its advanced, but it's also not an 80% use case), Or a setting that gets exposed, i.e, under settings, have a checkbox that reads "Enable to allow users to create empty text" Or something like that
B. It's not the overlay module. The overlay module makes the entire admin interface an overlay. This is different. I didn't expect this could be turned off, but if it could, it too would be a setting

#5
A. No good reason. There were all blue and right aligned at one point in time, but usability testing showed that the gears right aligned on the preview section were too far away. When I moved them to the left, that section started to look noisey, so I made them gray like other d7 gears. I probably need to turn all others gray too, but would side with usability over consistency.
B. Yes, probably. The one downside to that is that if disabled, it will look exactly like the Content Delete button that is enabled, but looks disabled (who's idea was that anyways!). Preferably, that delete button treatment should change so that modules like this can take advantage without breaking a pattern.

#7. Default is renamed to "master". Master only shows if there are no displays added, or if the administrator chooses to show the master. The only point of the master is to allow the user to propagate a change across displays, which we're now doing another way. So, it's really not needed. I only kept the concept around because a few people use just the master, and apparently there are modules that work with just the master.

#11. I didn't spend too much time on the actual content. More work is needed to make them less cryptic.

#12. The relationship is most used to least used & easy to understand to hard to understand

#13. Part 1 of the series should address this

#14. I had many conversations about arguments being more filter like. Unfortunately dynamic filters can be added to sort criteria too. If you have them in two places, you can no longer sort. This UI, coupled with a UI, that I'm working on as a replacement to arguments is the best solution I could come up with.

eporama’s picture

eporama commented

In case anyone else couldn't immediately find it, part 1 is #967892: Design proposal for /admin/build/views/add or /structure/views/add

Noyz’s picture

Noyz commented

I retract my Empty Text comment. Through a quick poll, this sounds like its being used quite frequently. I would like to come up with a better name though. Text is not empty :)

merlinofchaos’s picture

merlinofchaos commented

I called it "Empty text" because it is the Text used when the view is Empty. =)

JacobSingh’s picture

JacobSingh commented

How about "No results message" or "zero results message"

Bevan’s picture

Bevan commented

This is great! I feel like we've finally got something that works, scales and solves a lot of problems.

There is a checkbox on the advanced settings page that will make [the "master" display, previously known as the "default" display] always visible.... I think I like this because the default display is very powerful for experienced users and very confusing for new users. The one downside is that I worry that some newer users may never learn how it actually works.

In my experience new users are not likely to leverage this feature anyway (because they don't understand it). They are likely to create almost-identical but separate views with 90% duplicate configuration. It would be nice to find a way to communicate this feature clearly. However the concept would be a stretch for someone who is only beginning with views and already has a lot to grapple with.

Otherwise you need to klick a lot, to be sure, that the (node) is published, sticky, sorted by date descending
Also i think that "descending" should be the first and default order, this is what i use 99% of the time.

This can already be achieved by creating a view as a template and cloning it. I think it could be a useful feature for views to provide a basic node view with sticky and data sorts and a published filter, and (optionally?) use that when a site builder clicks "Add new view".

the Save button should never be hidden, only disabled.

I agree, however many themes, override button appearance so heavily that the disabled state is the same as or very similar to the enabled state. This is difficult to solve technically because the problem is really in the theme layer. Perhaps views can set opacity on the disabled button or semi-opaque overlay on top of it.

Sounds like [Empty text] being used quite frequently. I would like to come up with a better name though. Text is not empty

Perhaps "Text for an empty view", "Empty-view text" , "No results text" or "No-rows text"?

bojanz’s picture

bojanz commented

"No results text / message"++

many themes, override button appearance so heavily that the disabled state is the same as or very similar to the enabled state.

The mockups assume that we are using Seven. Other than Seven, I don't see that many admin themes being used (Rubik, a few more that might pop up), so the themes themselves can and should pay attention to the disabled button styling.

Mentioning Seven brings up the question: Are we considering this for the D6 version of Views too? Or D7 only?

merlinofchaos’s picture

merlinofchaos commented

D7 only at this time.

A backport is likely only with a D6 champion willing to drive it to completion. And I wouldn't even consider it until this is stable in D7.

phoenix’s picture

phoenix commented

Great work! Amazing to see this redesign. Can't wait to test it out.

Bevan’s picture

Bevan commented

The mockups assume that we are using Seven. Other than Seven, I don't see that many admin themes being used (Rubik, a few more that might pop up), so the themes themselves can and should pay attention to the disabled button styling.

Good call.

SeanBannister’s picture

SeanBannister commented

sub

bojanz’s picture

bojanz commented

#983272: Support click sorting for Field API fields just got it, the redesign overlords might be able to figure out something nicer in the redesigned UI :)

Fannon’s picture

Fannon commented

When will those redesign Ideas be implemented in Views?

Greets,
Simon

bojanz’s picture

bojanz commented

Simon,
The unofficial deadline is DrupalCon Chicago.
Acquia has started work on GitHub.

j. ayen green’s picture

j. ayen green commented

Will there be any views-ui module snapshots before the release? And are the mock-ups reliable?

dawehner’s picture

dawehner
Primary language German
commented

You can track the development on github. That's currently the only space where development happens.

j. ayen green’s picture

j. ayen green commented

Right, looking there, but I only see one 7.x-3x tree, with one version of views-ui, which I assume to be the original UI

bojanz’s picture

bojanz commented

Everything there is "the new UI", or at least the beginnings of it.

merlinofchaos’s picture

merlinofchaos commented

My guess is that the 5 day mid-Feb code sprint will show us a giant burst of progress. I have vague hopes that what we come up with then will be committable to -dev.

Itangalo’s picture

Itangalo commented

Subscribing.

(This work is awesome.)

Noyz’s picture

Noyz commented

This is a link to some updated designs for this. Not much change, just easier to update all the designs at once:

http://viewsdesigns.drupalgardens.com/node/6

dmitrig01’s picture

dmitrig01 commented

These look really good. The direction these are going is great.

  • I think the interface in 08-10 is really easy to use, but once you use it once, it goes away. Is there any way to incorporate that into later parts?
  • On the view listing page, I think the word "template" might be confusing, because templates are also .tpl files
  • I think that while the surrounding chrome is greatly improved, it doesn't fix the confusingness of the Advanced Options -- I'm not sure I see how it's realistic to build a view without these.
  • This may start suffering from a case of too-many-clicks-necessary-itis. For example, in the live preview/edit, I think the title should just have a little edit button instead of the gear -- what other operations could go here?
  • Similar thing with the header -- what about just having an edit button, and it could change to a more complicated configure option if/when another header thing is added
  • How does one rearrange filters?
  • For the content dropdown in #12, it seems that that could potentially be a lot, as it has to encompass all filters, sort criteria, and fields. Could those be split out into three dropdowns each with a different icon? And, maybe a fourth dropdown could be added for Format (table/list/etc)
Noyz’s picture

Noyz commented

I think the interface in 08-10 is really easy to use, but once you use it once, it goes away. Is there any way to incorporate that into later parts?

I started the design this way. I was an advocate for this myself, but deviated at some point due to some feedback that I can no longer recall. I'll look back into it and see what i can do.

On the view listing page, I think the word "template" might be confusing, because templates are also .tpl files

I'm not to concerned with that. "template" means many things in many places. Themers at that are at the level of understanding templates and .tpl files should be able to differentiate. That said, Im open to other suggestions that would still help users grok this concept of code based views.

I think that while the surrounding chrome is greatly improved, it doesn't fix the confusingness of the Advanced Options -- I'm not sure I see how it's realistic to build a view without these.

There are many many views that can be created without relationships and arguments. The reason they are hidden is because when exposed by default, new users have that much more to grok, and therefor Views becomes that much more intimidating. The section drops a cookie and stays open for users that understand the concept. I also agree with you that it doesn't completely resolve the problem. My research shows that people expect exposed filters, arguments and filters to be accessible and be more integrated together - but Views cannot handle this without going backwards in functionality a bit

This may start suffering from a case of too-many-clicks-necessary-itis. For example, in the live preview/edit, I think the title should just have a little edit button instead of the gear -- what other operations could go here?

any filters or fields assigned can be directly edited. New fields can be added. The default appearance of a view is collapsed (http://viewsdesigns.drupalgardens.com/sites/viewsdesigns.drupalgardens.c...), so people don't even have to interact with the UI that we know of today unless they choose too. So, I'd say it's exactly the opposite.

How does one rearrange filters?

See callout #2 here: http://viewsdesigns.drupalgardens.com/node/6

For the content dropdown in #12, it seems that that could potentially be a lot, as it has to encompass all filters, sort criteria, and fields. Could those be split out into three dropdowns each with a different icon? And, maybe a fourth dropdown could be added for Format (table/list/etc)

Sounds like a module. For most views, this shouldn't be needed. Note the callout here: http://viewsdesigns.drupalgardens.com/media-gallery/detail/6/66 The whole point of these UI's is to reduce complexity on the surface.

bojanz’s picture

bojanz commented
Status: Active » Fixed

The new Ui has been committed to 7.x-3.x.
Mission accomplished.

Itangalo’s picture

Itangalo commented

Wohoo! Congrats to everyone involved!

I've started publishing a screencast showing how to use Views from really basics to advanced configuration – with the new UI! I saw that the project page says that is no documentation available right now, so I thought that this could be of use.

It can be viewed here: http://nodeone.se/blogg/taming-the-beast-learn-views-with-nodeone

bryancasler’s picture

bryancasler commented

epic update!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.