Views UI Thread the Second

first, many congratulations for the progress so far. terrific work, team.

• assuming user has javascript, does the edit View page ever refresh or is the save button the only way to do that?
• are we using ahah for form elements or is the form all coming down at once?
• some modules like date.module use lots of Views1 features for fields/filters/arguments. we should just make sure that all this fits comfortably in the new UI. I think it does - just making sure.

Using the current Views 1 and couzinhubs pdf as reference, here's an initial wire frame of mine for the UI of Views 2:

http://www.scribd.com/doc/1555244/Views-2-UI-v1
(its the first one I've done for views 2, it usually takes about 15 revisions to get to a workable wire frame.)

P.S. Drawers are another name in use for vertical tabs.

I don't have long for this message, so I won't go into much detail, but generally;

@Couzinhub

I feel like 9 is the best we've got. I'm not sure if 10 is an improvement. IMO 11-13 are steps backwards. They break the simplicity of the UI from the POVs of both usability and technical implementation.

@SteveJB

Views is HUGE. There are a LOT of concepts, context, background, technical detail, features, relationships, hierarchies to grok. I have been using views1 for over a year and I wouldn't say I've near grokked it. If you haven't had much experience with views, you could find it time consuming and difficult to contribute. I don't mean to be discouraging -- your input is appreciated. I just thought I'd let you know so that you are aware. :)

Bevan/

couzinhub, thanks for the great mockups so far. I have some suggestions to help with integration in Drupal 6 that hopefully will both be easier to use and implement.

• On the up/down arrows: These should just be replaced with the draggable icon included with Drupal 6, which will be the standard convention for drag and drop in Drupal 6. It'll also save writing a lot of redundant javascript by using the existing code from core. If we don't like the look of the arrows we could swap them out with CSS, but being standard I'd probably try to stick with the stock icon.
• Degredation and accessibility: I know this isn't something that Earl plans to implement in the initial release (usable without javascript). Maybe it's something that we can think about as we progress though. Try to use buttons whenever possible when performing an action, not just table cells. Providing buttons (they can be image buttons) provides tons of benefits:
  1. They indicate to an end-user how they can perform an action on something. The [ + ] and [ x ] icons are a good start to this. Perhaps we can extend it with a button for "edit", like the traditional pencil icon?
  2. They make the form accessible. Some one that is unable to use a mouse can tab through form elements on the page and use the spacebar button to activate the button. After reading this request by a community member about accessibility, I'll never write a non-accessible module again.
  3. Finally, they'll make the form (possibly) degradable. A standard way of dealing with the lack of javascript is to only perform actions that will update data with buttons. If javascript isn't available, no problem. It just submits the form with the current state and loads the page again with the new state. I realize this probably won't happen for the initial betas, but if we plan for it we can write in the functionality at a later time.
• I agree with Earl about modal dialogs. We should probably stick to the edit area down below for various actions. This will save quite a bit of javascript and it's not yet a Drupal convention. Drupal 7 though, will likely be another story concerning modals.
• Could we show the "Add Filter" form all the time at the bottom of the current list of filters (when editing filters)? This would basically mimic the contents of the Views 1 form for adding filters (or other views properties). The list of current filters is displayed above, while the form to add a new filter is displayed below. This makes it so I don't need to click the [ + ] icon every time I want to add another filter, easing the initial setup of a view quite a bit.

I really don't mean to be intrusive with chatter but with nothing to follow it up. You've done excellent mocks couzinhub. I'll see if I can shift my priorities around and help merlin implement these things wherever I can help.

So am I right that the layout you are following in implemantation is the one of couzinzub? http://www.couzinhub.com/Views2-UI/views2-9.pdf

Cause this would make me jump with joy ;)

If we get to this kind of standard in UI, the rest of drupal will be obliged to follow... YAY!

Life is a process

@couzinhub Could you upload the graffle files for 7 and 9 please? Thanks! :)

Bevan/

A new episode in the long process of the UI. Icons are mostly place holders, some from the Silk Gallery, some from me.

missing : the ADD and REARANGE icons..

http://www.couzinhub.com/Views2-UI/views2-15.gif

The Drupal Agency >> www.raincitystudios.com <<
Me on the Web >> www.couzinhub.com <<

Are those place holders for future icons? Since I doubt there is actual need for icons in front of the titles, such as view settings. By the labeling it can be confusing I think. For allot of people the :

What, Where and How.

What = basetable: node, users, taxonomy
Where = as a page, a block or something defined by another module
How = Unformatted or List or Table. Then narrow it down to item level: teaser, full post or handpicked set of fields.

Will probally make allot of sence, however the ui labels dont communicate this as drastic. I'd like to take a better look at everything before I get more indepth.

As a "first-use" comment, when I began experimenting with the new Views 2 UI, I misinterpreted the "Rearrange" icon in to the top right corner; instead of rearrange, I intuited the arrows to mean "Refresh", and thought that I would use it if one of the sections needed to be manually updated (like a page in a browser). After using it for a bit, the meaning of the icon is very clear to me now. I didn't immediately get it on first sight, however.

And now to my humble suggestion/thought:

Complex tasks in Drupal, like building new content forms or assembling views, essentially ask users to imagine and/or remember what the end product might actually look like over a period of time. In the case of views, the task set is fairly complicated and that period of time may be rather long in 'user time,' even for skilled users.

The high-level summary you've added (http://www.angrydonuts.com/views-6-x-2-0-alpha-2-released) does move us more in the direction of good feedback for users: "what have I selected?". But the most direct method of feedback, I think, would be to offer a in-context preview for each display type. I'm thinking of an AJAXy kind of preview that does not require users to navigate to a separate page (and then possibly lose the submission state). Perhaps this would be as simple as running and displaying an AJAX query based on the current view configuration each time a user selects a preview tab/button/link?

Would this sort of thing be technically viable? Thoughts as to the desirability of such a feature? As I've hinted above, I do wonder if this pattern (in-context preview) might fit elsewhere - heck, it's already below me as I type!

The latest incarnation is, needless to say, completely awesome - nice work!

Just wanted to comment on the preview idea before tossing in my $.02. For Views, as Earl mentioned there's a lot affecting a View, and you have to account for blocks and page styles, unwieldy pages (a long View popping up beneath a form), and more. Right now my M.O. when making a View is to use two separate tabs in my browser... on one I edit the View and simply use Save/Edit and on the other I refresh the page. This sort of "live preview" is a lot more effective than making a change in a form, updating it, and browsing up and down the same page. It also serves the purpose of showing me what the View will look like in an actual context. I understand it's not a live preview in the context of the edit page itself, but that just really doesn't matter to me. (I may just be a preview snob, though... I don't really care for the comment preview thing going on here.)

Onto my own feedback... thanks for all your work, Earl. I use this stuff all the time and love the flexibility and power behind it. I'm hesitant to offer too much feedback having only test driven the new UI once, so I'll keep it to a few short ideas. I don't want to step on any toes or "complain" about something that may be in the works. When I get some time to follow progress a little more fully, I'm sure I can be more helpful.

I'll provide the disclaimer that I use Views a lot and am familiar with the existing UI. Also, I've never been bothered by the monster form format and in fact find it useful. It lets me test drive a View, keep a mental note of a few things that tweaking, and go tweak them all at once. So, some of my thoughts are related to whether or not the new UI provides a benefit over the old, and I'll leave it up to others to decide if I'm just stuck in my ways. ; ) (Props to Earl for making the old UI usable even as a monster form!)

1. My main feedback would be that I just didn't know where I was any more. : ) I was looking at a form with a lot of short labels and missed having the queues from description text on fields so I could know what to do where. For example, I feel like I should've known this already, but looking at basic settings and seeing fields called Name and Title threw me off. To figure out which was which, I had to click on them separately and wait for them to load up and find the descriptions. My proposal is simply to think about implementing tooltips so I can hover over an element and be reminded of what the field is for. For other things, like lists of fields, filters, etc. tooltips could provide a summary of field specific settings. Perhaps I'm a little tooltip happy. : P But I think they could be used to good effect to help at least newcomers or people converting from the old UI to navigate the form a little easier. Bonus points if they can pull descriptions or summaries straight from the forms so you don't have to write original tips (which is what my w.i.p. form summary does).
2. I'd recommend not making Relationships, Arguments, Fields, etc. link. Right now it seems like they simply go to the rearrange page which users have an icon to click on for the same action. Seeing the link on it makes me think it's either going to show me a page of settings for the field as a whole or modify the contents all at once (which would be great! a la existing fieldsets on the old UI). I think these things instead of "rearrange" since modifying settings is what all the other text links on the page do.
3. It took a lot longer for me to setup a View. This is because now I can only edit a single field at a time whereas before I could zip through and fill out all the fields at once. I'm speaking primarily to the Basic Settings elements. My recommendation here is to either make it possible to click a button to access all these form elements at once from the edit page or (and Lyle liked this idea better) let me set all these basic settings on the Add form. For the former idea, this is great since these settings are really only going to be edited in bulk the first time. After that you're most likely just going to be tweaking something here or there. (<aside>Eww... as this post gets longer, the comment preview is getting more and more annoying.</aside>)
4. It would be helpful to have a Views link in the breadcrumb when editing a View so I can more easily get back to the overview page. : )
5. This may already be known, but expecting to use enter to submit a setting form does something different. Couldn't quite put my finger on it, but it may have been it was just trying to submit the "Override" button. I got around this on the checkout form w/ a work around to add the "Update cart" button prior to a "Continue shopping" button in the HTML even though the shopping button displays first. Don't fully know if that's the case here, so I won't speculate on an exact fix. At least as a user, I expected enter to default to Update. (You can duplicate this when editing the title.)
6. Don't know if I should post this as a UI item or not, but I'm here and typing now. : ) If you click on a field to edit its setting and then switch vertical tabs, the field's form will persist in the bottom of the interface. It should probably get closed or at least altered to indicate it's a setting for a different tab.

That's all for now. Let me know if I've stepped on any toes or missed something in the development process. My apologies if I've repeated feedback or added to frustration, and I hope to be more helpful in the future.

Ciao,
-Ryan

Yoroy : I think for people to understand the point I am trying to make its key to understand that we 2 completely different users of Views, those who actually know what they are doing "I hope" (mostly developers and themers) who are familiar with the words used in views module. And the people who pretty much aren’t, the users that are not developers nor coders but do want to achieve the same results as the developers.

I personally think the biggest usability problem is the use of words(descriptions) for 2nd group. Which make allot of sense to a developer but to a non-dev really doesn’t. However fixing and finding better words and descriptions is incredibly hard (and not pissing the developers off :D) I will no try to give my interpretation of what the vocabulary of the user (the non-developer) is and throw in some usability tips occasionally.

Basic Settings

Page: The name of this display
Why would you add Page in front of it? It is an indicator that is already given by the tab, and only adds more text to an already complex task. I think the description could be reformed to : This is the title that will only appear in the admin of Views. Its shorter and therefore more likely to be read and understand.

Title: The title of this view
I think most new users will be unable to understand, what the difference is between the name of this display, and the title of this view. However, by changing either the description to something more obvious : This title displayed publicly, , wherever titles are normally displayed; i.e, as the page title, block title, etc. I think there could probably be a better description or word that will make a distinctive difference between the name and title forms.

Page: How should this view be styled
Perfect!

Row Style
So there are 2 values, the node text implies it references to a node (fairly obvious) however field, doesn’t really imply anything other then field is this about a field in a node? Ie an example of what a field is could be useful here.
Field
Node

Pager
I cant tell what this from the name, does it mean a beeper? I think this is hard to call different or to have a more obvious explanation as it is a fairly developer focused function.

Items to display
Perfect! However, I am thinking couldn’t Offset be changed to Skip the first ... items?

Path (Please just call this url?)
I think everyone gets its /path and not the full url. So the difference between path and url shouldn’t really be made.

Arguments
Users would need to identify this, as is this a what, where or how? I am wondering if they can. The list seems obvious, apart from the scrollbar and the cck added argument? Wouldn’t this list become very long with allot of custom arguments?

Fields
There is a drop down Date format with Small, Medium, Large, Time Ago and custom. Wouldnt it be better to actually display the current time in large, small and medium format in that field? Time ago and custom are fine.

Sort criteria
Great, however I think some users will get confused by multiple ascending and descending criteria, they will confused if this might not possibly conflict with each other.

Thats about what I could spur out, hope it helps :) It would probably be more easier for the real beginning to list the functions in the what, where and how format, however I am quite sure this would have a negative effect on the user experience of the developers.

Page : Oke, thats seems good. It seems the piece I wrote about the tabs has dissapeared in my text. I think the tabs right now could be improved visually, although the white tab now is used to indicate the active(content) area. Visually this is somewhat wierd, I think the easiest way to fix this is to apply borders that connect the white tab to the content area.

Pager, I can understand why you say this. However I still think that quite some people wont use this function, the description is to hard to understand for non developers.

Thanks for the fast response