Views UI Thread the Second

merlinofchaos's picture

Now that I've narrowed down a direction, this thread is for commentary. Rules:

We're going with vertical tabs.

We're going with the summary above, edit area below.

There are only two actual steps for creation.

I'm already working on the implementation.

The WIKI is here: http://groups.drupal.org/node/8428 -- it may be edited to include things we know or like and wish to pursue. For speculative commentary, please put it in this thread.

Comments

fapi questions

moshe weitzman's picture

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.

This will be ajaxy

merlinofchaos's picture

This will be ajaxy javascripty goodness. The summary should be refreshed via javascript whenever any of the subforms are submitted.

The form area in the mockups is a bit smaller than what I've got. Actually, I've done some implementation work; I should post a screenshot.

As of today, this is what I

merlinofchaos's picture

As of today, this is what I have. The vertical tabs work (yay) but that's about the extent of it. It'll probably take me a bit to get the ajax working properly, but I don't think it will be too terribly bad. I've got a fair bit of ajax forms experience now. =)

http://views2.logrus.com/views-ui2.png

Updated UI

no longer here 133581's picture

So this new updated version has a new wireframe for the general settings, working the same way the display works. Also, it would be possible to re-arrange fields directly, but to add/edit, there is links that would open a panel-like window (javascript popup I guess ?) to change the settings.

I changed a bit the rest, like tabs content and add seperators to each clickable area for the displays. I think we should have a hover state that would show that you can click on the area to edit it.

http://www.couzinhub.com/Views2-UI/views2-10.pdf

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

Update UI #11

no longer here 133581's picture

Basic settings inside display settings, and first try of pop up...

http://www.couzinhub.com/Views2-UI/views2-11.pdf

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

I don't think we need

merlinofchaos's picture

I don't think we need popups. I was going to have each filter/field/etc clickable directly in the summary in order to edit it. While I was very interested in popups early on, I think they may be a bad thing here, and we should stay away from them unless we decide they are needed.

I'm confused by the arrows in the summary -- are they going to be directly movable in the summary? If so I'll have to think about that. It may be doable, actually, but the arrows might take up a lot of space, even if we make them very small. Will have to see.

Using the current Views 1

SteveBayerIN's picture

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.

Latest Updates

Generally

Bevan's picture

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/

No one has commented on this

Bevan's picture

No one has commented on this thread over the weekend. I guess everyone works on this during the week. It's great to see so many folk being able to work on this at or as (part of) their jobs! :)

I've commented on specifics in screenshots on flickr. Here is the first in the set (remember flickr orders most recent first, so it makes sense to look at the screenshots and read the descriptions 'backwards'): http://www.flickr.com/photos/89495529@N00/2223628739/in/set-721576038078...

Rather than commenting on flickr and threading this discussion even more, please respond to my points here. (On second thoughts, Maybe I should have posted my comments here?)

I used the tag views2ui which we should make standard on flickr for flickr posts, along with drupalui which is what most use for drupal ui stuff already. I also tagged them couzinhub, since he's the creator of these wireframes. I used Skitch which I highly recommend for these sorts of discussions. It makes taking screenshots and uploading them really easy.

Bevan/

I may have lost track of

merlinofchaos's picture

I may have lost track of stuff as I don't fully recognize the mockups you're using. Though couzinhub did make several in a row there, so I may have missed some subtleties.

The file name that each

Bevan's picture

The file name that each screenshot was taken from is in the title of each photo, if you do want to look things up.

Bevan/

Suggestions

quicksketch's picture

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.

On the up/down arrows: These

merlinofchaos's picture

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.

I am a bit iffy about using the new core drag & drop stuff, because it relies on weights still, and I really detest the system of weights; I worked hard to not use weights at all in Views 1, and I thought it was a win there. I would consider having to revert to weights to use this functionality a step backward.

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:

I actually am going completely degradable with the current direction, and have gotten an excellent start on the code. I've created AJAX forms that work well in both the js and non js context. The reason for the design as it is now is that the main edit page has no from gadgets on it at all purely for the purpose of degradability. This means that everything is a link which then goes to an actual form. In the js world, that form is ajax'd into the edit area below, and when it is accepted, the changes are stored in a temporary location on the server. That code is actually functioning, too.

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.

This breaks the basic paradigm of small forms with single purposes; that creates two forms. Also, the 'add filter' dialog will have checkboxes and let you add several at a time, so I don't think this is likely to be a major impediment. The workflow for all of these items will, I think, be this:

Click add filter
check 5 filters
-- for filters, rearranging isnt necessary. For fields, it would be, though, so the step remains.
click each filter and edit its values.
Save the entire view.

It is a few more clicks than the old Views 1, but the clicks are a lot faster, and there is very little scrolling.

If I try to put the add filter form in when a filter is being edited, I think the form would be somewhat confusing, as well as causing unnecessary scroll.

Woot!

quicksketch's picture

I am a bit iffy about using the new core drag & drop stuff, because it relies on weights still

The drag and drop system doesn't necessarily mean "weights". Views 1 uses "position" which is essentially a weight where every value is unique. Fortunately this works extremely well with drag and drop. When you move an element, it recounts from 0 (or the top element in a select list) down to x (or the bottom element in a select list). It's purely a javascript implementation of setting values in select lists, hiddens, or textfields. You'll see in Drupal 6 if you arrange your blocks, in the database each block is given a unique weight. It was just the easiest way to go about it.

I actually am going completely degradable with the current direction, and have gotten an excellent start on the code.

Fantastic! This is contrary to what I'd heard earlier. Great to see Views is headed in this direction! Links work just as well as buttons for accessibility so there's no issue there. The way we've done most AHAH stuff in core has been by using a button and then simply hiding it if javascript is enabled for degredation. I assumed you'd use the same method but links will be peachy.

This breaks the basic paradigm of small forms with single purposes

That's fine. It was a weaker suggestion that I thought would make Views 2 familiar to current users and save some clicks. Maybe we can consider it at a later point after we're able to try out the UI.

All in all, I've very excited to see where this is going.

My main issue with weights

merlinofchaos's picture

My main issue with weights is that in the degraded case, you get the select boxes and then Views will have to translate that back. The reason I went with the arrows is that I find weights particularly difficult to use; especially when you modify something that's already been set up; whereas the arrows are straightforward, even in the degraded case.

This isn't to say I won't use drag & drop; I happen to have a drag & drop implementation somewhere that I suspect I could re-use, and make it at least appear consistent with core's.

Following the ongoings

eigentor's picture

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

Life is a journey, not a destination

Basically yes, but without

merlinofchaos's picture

Basically yes, but without the 'general settings' box. Everything is in the one box, with the UI form below it. I'll post another mockup soon, I hope.

Do you mean like the layout

Bevan's picture

Do you mean like the layout and vertical tabs in http://www.couzinhub.com/Views2-UI/views2-7.pdf ?

Please keep us updated with progress! :)

Bevan/

No, I mean much more

merlinofchaos's picture

No, I mean much more literally like 9 without the box above it. No vertical tabs for filters/sorts/etc.

@couzinhub Could you upload

Bevan's picture

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

Bevan/

There you go ! :) Sorry guys

no longer here 133581's picture

There you go ! :)

Sorry guys I've been a bit quiet recently, I went through an eye surgery, I'm all good now but I'm still a tiny wee bit blurry, I'll start working again on the UI asap.

http://www.couzinhub.com/Views2-UI/graffle-7-9.zip

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

A new episode in the long

no longer here 133581's picture

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 <<

If you've been working on

Bevan's picture

If you've been working on Views2 UI, you should read this: http://lists.drupal.org/pipermail/development/2008-February/028860.html

Bevan/

Couzinhub

Bojhan's picture

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.

I'd be very interested in

yoroy's picture

I'd be very interested in your feedback on how to communicate the What Where and How even stronger, please do report!
Also, I'd have to agree that the icons in front of the titles of the setting-groups are more distracting than helpful there.

Rearrange/Refresh

keith.smith's picture

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.

Hmm. I see. I'm not sure

merlinofchaos's picture

Hmm. I see.

I'm not sure there's an easy 'fix' for that first impression, but it's valuable knowledge. Will have to ponder it.

Views Real-Time Preview Tab/Button/Link

libsys-gdo's picture

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!

It is definitely possible to

merlinofchaos's picture

It is definitely possible to provide a preview. It is possible to provide an in context preview.

However, I'm not sure how realistic the in context preview will be. A preview is going to depend on several things:

1) Each display can have its own preview.
2) A preview will be highly dependent upon the arguments; as such, a box for preview arguments will be needed.
3) Between the summary and the ajax landing pad, putting this preview automatically beneath the form might be problematic. It is not impossible, and it may be something worth experimenting with. It might be a case of having a little form down there that enables it, with the argument settings and a checkbox, and while that checkbox is checked, every time the view is changed it will ajax in a new preview, perhaps.

That's kind of neat, and could be very useful.

Just wanted to comment on

rszrama's picture

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

My main feedback would be

merlinofchaos's picture

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).

I'll consider tooltips, sure. I realize that there's a bit of "Where do I start?" for people not familiar with the UI, though in my testing, the AJAX mechanism responded so quickly that I didn't feel like it was a burden at all to click and load the form and get more information. As you describe it, you have noticeable lagtime loading the AJAX form?

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.

So here we have a chicken and egg problem. Right now, 'Override' lives on the rearrange page. Which is NOT where I think to click when i want to override the filters for a particular display. Thus I made the title a link to the rearrange, so that I can easily get to the override. I could make override a form completely by itself, but that feels wasteful. That said, I may have settings specifically for at least some types in the future, so that might change in the future anyway.

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. (Eww... as this post gets longer, the comment preview is getting more and more annoying.)

Accessing all the elements at once in the ajax pad isn't likely to happen. And I'm afraid that making the 'Add' form long by adding a bunch of widgets is iffy; it might be doable, but I am afraid of the side effects of throwing too many fields at the user at once. I'm trying hard to avoid the cockpit effect.

That said, here is a compromise idea. I'm not sure if you noticed, but when you add multiple fields/filters/sorts/etc, you get sent to the config page for teh first one...and when you update, it basically cycles through them.

For regular settings, it would be fairly easy to create a "Update and Next" button that basically steps through these, thus you'd start at the top and sort of tab/page through the various settings fairly easily. What do you think of that option?

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. : )

It would, wouldn't it? Blame the menu system. It should be generating a breadcrumb link based on path, yet it is not. I think it's tab related. Someone submitted a patch that fixes this in a different way which works out okay too.

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.)

It's such a pain to control what the enter button does. I'll see what I can do -- I might be able to set the override button late in the tab order or something.

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.

It does stay open -- and this is valuable because you may want to compare a setting from one tab to another. Also, the item you're editing is hilited, and if you switch to another tab, you might find that 1) you're editing it there too (the magical power of defaults) or that you're not because it's been overridden. I like the current behavior, myself, but I did have to play with it awhile before I came to that conclusion.

Finally:

I'm working on the design for a live preview. It'd work...actually a bit like the live preview does here.

Thanks for taking the time

rszrama's picture

Thanks for taking the time to respond. Definitely not trying to dump any extra work on someone else, and the things I mentioned I'd be just as happy making into a module that I could use if it bugged me enough. : P

The compromise solution for basic settings sounds good, and I'd be happy to test. The main advantage there is you're not having to keep switching your attention up and down from the overview to the settings form.

Regarding the breadcrumb, is this an issue w/ Drupal itself or was the patch just to manually throw up a breadcrumb using drupal_set_breadcrumb()? If we need a patch to get reviewed for core, let me know and I'll check it out here at work. I'm sure that will affect some Ubercart settings menus. : P

Also, regarding the highlighting when switching tabs, I realize now that my trouble w/ it could be related to my work LCD monitor's sucky contrast ratio. I'll check it out again from home, but I think I see what you're saying. : )

I'll keep an open mind about the preview, too. ^_^

Thanks again,
-Ryan

The change turned the edit

merlinofchaos's picture

The change turned the edit into a local task which causes the breadcrumb to show up. So it'll be better next rev.

To expand a bit on the highlighting, if you didn't click 'override' on a particular setting, then when you change it on one display, you're changing it on all displays.

Figured that out and tested

rszrama's picture

Figured that out and tested at home... contrast ratio is much better on my CRT, so I think I liked the functionality, too. : ) As a suggestion here, unless you've ruled it out in previous testing, it might make more sense to default edits on individual displays to be overrides (since I'd expect to go to the defaults tab to alter the defaults) with a button to make the changes to "affect all displays" or something like that.

I've thought about it, but

merlinofchaos's picture

I've thought about it, but the nice thing here is that when you add a display, it picks up all the defaults automatically. If they start as overrides, then they have no real settings. Or they have to copy their settings.

Also, the general use that I can see is that a given display is only going to tweak a few settings. The rest will be defaults. This is especially true of the filters/fields/sorts/etc where you couldn't even override those before, and I don't think those will be overridden all that much.

Vocabulary user

Bojhan's picture

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: The name of this

merlinofchaos's picture

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.

If you click around a bit in the drawers, it may not be clear exactly which tab you were on when you opened the form. This is in there for clarity.

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.

I disagree with this assertion. It is lingo, but it is not a fairly developer focused function.

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

The 'skip the first ... items' should be in the description of the field, but the name of the field needs to be fairly short or it's very difficult to discuss the setting.

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?

I don't think it's common to have more than about 3 arguments on a view. Arguments is a difficult word, but it's also one that's been used a lot historically and thus it already has recognition.

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.

I can see this.

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.

There comes a point where we have to decide how much training in database-isms we're going to give the users. This is a point I decided to just accept and deal with in documentation as much as possible.

Re : merlin

Bojhan's picture

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

There have been several

merlinofchaos's picture

There have been several complaints about the color of the tabs, and this definitely needs to be addressed.

I'm not sure. The concept of the pager is used a lot in Drupal; with even a little exploration, most people should run into it somewhere, so I'm not convinced that most people won't at least figure it out. I will grant that not everyone will intuitively understand it. Will see about cleaning up the wording on the description.

pager

catch's picture

I agree that 'pager' is a perfectly reasonable term given it's ubiquity within Drupal and it does after all deal with 'pages' of stuff. However if you have a better idea for a term then please open a core issue so we can change it consistently.

However the description could use some work so I opened an issue on the views queue with a first run at revising the text, hopefully see you over there: http://drupal.org/node/232431

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week