Views UI mockups

public

groups: Designers and Information Architects · Usability · Views Developers

yoroy - Sun, 2007-09-23 18:41

Hi. I'd like to document some links to Views2 UI mockups here. Links to the files have been bouncing around in IRC, maybe this can be a place for further thoughts on how Views2 could best present it's functionality to the user. I'll be updating any new screens here.

These all concern the “create new view” part of the UI, looking for ways to present all the available settings in a more compact layout.

first:
- views2-merlinsmockup.png
merlinofchaos' first html mockup, using 2 columns for some of the settings. This does win quite some space but may be not so clear in indicating which applies to what, it's not really clearhow these 4 litte blocks relate to the big one above. Also knowing the amount of options there are it might be a bit optimistic to try and cram them in half the available widht.

Views-UI-bottomdrawer-b.jpg
My personal feeling when creating a View in the current UI is that I'm "drilling down" through all the options. Based on that I came up with this, which sums up Relationships, Arguments, Filters and Sort Criteria in a vertical list but as tabs. This way the form for each could be in the same area. This introduces a new style of tabs which might be undesirable.
Views-UI-doubletabs.png
So I mockup the same concept with the default horizontal tabs above. This loses the "drilling-down" feeling (which might be just a personal preference) but also disconnects the lower part from the upper. I know the new Views will make it so that Relationships, Arguments etc. can be set differently for each type of output you'll define for your View (e.g. Page-view can have other filters than the same view rendered as a block, right?)
views-ui-3steps.png
Finally, I took some hints from Panels module, which has more linear, sequential approach in the UI, first do foo, then add bar, etc.
I tried to apply same to Views in this mockup. Don't know if this is possible, but I think a little hand-holding, step-by-step approach could be good for the complex beast that is Views.

I hope I'm helping here, and not confusing things more. Any feedback? It'd be nice to hear how non-devs go about creating a View. My personal analogy is that Views is to Nodes as Smart playlists (in iTunes) is to Songs.

Attachment	Size
views2-merlinsmockup.png	42 KB
Views-UI-bottomdrawer-b.jpg	74.21 KB
Views-UI-doubletabs.png	36.33 KB
views-ui-3steps.png	44.15 KB

Sitewide tags: UI · views

» Login or register to post comments

I like...

ccharlton - Mon, 2007-09-24 18:03

views2-merlinsmockup.png - clean, small, this was my favorite so far.

Views-UI-bottomdrawer-b.jpg & Views-UI-doubletabs.png - are okay, bottom drawer looked nicer to me, doubletabs looked standard Drupal.

views-ui-3steps.png - reminded me of OS X apps, which isn't bad. Great start and I like wireframe more tha mockups since people don't get stuck on unimportant details.

thanks for looking

yoroy - Tue, 2007-09-25 09:29

I got tired of making screengrabs too, I'll stick to wireframes in OmniGraffle from now on.

I think

dmitrig01 - Tue, 2007-09-25 03:45

Unfortunately, some of the concepts are wrong...

So I mockup the same concept with the default horizontal tabs above. This loses the "drilling-down" feeling (which might be just a personal preference) but also disconnects the lower part from the upper. I know the new Views will make it so that Relationships, Arguments etc. can be set differently for each type of output you'll define for your View (e.g. Page-view can have other filters than the same view rendered as a block, right?)

As a matter of fact, no. Only fields can change, but filters, sort, and arguments stay the same for every display type (the tabs in merlin's mockup).

Ok, thanks for explaining.

yoroy - Tue, 2007-09-25 09:22

Good to know. I'll try to update the mockups accordingly.

Had a 'wild idea,' since I

amitaibu - Thu, 2007-09-27 18:45

Had a 'wild idea,' since I saw it already most if it in panels 2.

How about making all the different blocks (e.g. arguments, relationships, etc') - in JS panes. Like this user can do two things:
1. move them around as they wish, and to place them according to their needs.
2. collapse/ expand panes.

I prefer the last mockup

Wim Leers@drupal.org - Mon, 2007-10-01 11:02

I prefer the last mockup (the 3-steps, Panels 2-ish one). If only for the sake of consistency in Views 2 / Panels 2 administration UI, I think this is the best. All 3 others are not 100% clear about the fact that you can't have settings for each different View output.

I agree with Wim, I like to

amitaibu - Tue, 2007-10-02 20:33

I agree with Wim, I like to panels 2 UI

I actually dislike

brenda003@drupal.org - Tue, 2007-10-02 22:50

I actually dislike multi-page as it can take longer if you're working with a lot of views. I haven't looked at Panels2 to compare, but I like the first two mockups.

Right on

gaele - Wed, 2007-10-03 22:45

The current views UI is quite complicated, so I applaud any improvements. I'm happy to see this is being worked on.

My feedback:

The first one is way too crowded. There is no reason for the 2 by 2 arrangement other than to save space.

Second one is better. Disadvantage is the new tab style, as you said. And still feels a bit cramped.

Third one is worse. How does the second row of tabs relate to the first row? Hierarchical? Are they independent? It's not clear.

That leaves the fourth one. Which I actually like. Two rows of tabs, but the hierarchy is clear.
This could be one page with a bit of jQuery (e.g. jstools with Tabs (example)).
A few improvements:
- Leave out the word "View" from the tabs. It should be clear from the page itself that it's about Views.
- "Info" and "Settings" are too general (the whole page is about settings). Info could be "General". Settings, I'm not sure.
- Leave out the Next arrows. The steps should be clear from the tab design and order. (If there are two places to click on for the same action there's something wrong with the user-interface.)

Views UI 3 Steps

Rob Loach - Thu, 2007-10-11 15:47

I really like views-ui-3steps as it doesn't display too much information to the user at any given time. The suggestion from gaele regarding JSTools with Tabs (this) would really speed up administration and avoid the frustration when doing a lot of Views manual labor tasks.

Yeah 3 steps looks good.

catch - Fri, 2007-10-12 11:54

Yeah 3 steps looks good. Using jstools tabs - you mean no ajax calls between tabs unless there's a save/update? That'd be great yeah since I often have to check things back and forwards in the single page view.

+1

irakli - Mon, 2007-11-19 22:36

views-ui-3steps.png is awesome

three

tjholowaychuk - Thu, 2007-11-15 01:28

three is my favorite of the bunch. I agree that views should be welcome to use a wide array of JS tools, I find myself annoyed even using views simply because the page takes so long to load at times, anything to make this more interactive and intuitive would be great.

vision media
350designs

Tabs are nice

Laura - Thu, 2007-11-15 20:59

Using ajax/dhtml tabs to replace the dhtml field groups in the current UI could be a nice change. I don't quite understand the last mock-up, with "next" links -- I am constantly moving through the different settings in a view and don't consider it a serial process. Having tabs in the order the field groups are now would convey enough of a serial nature.

I'd also recommend having a class set on any tabs where settings have been defined, so that one can see at a glance that, for example, fields and arguments have been set but the sorting order has not.

Laura
pingVision, LLC

I agree

tjholowaychuk - Tue, 2007-11-27 18:50

It would be nice to have a visual notice of which sections have been altered or not

vision media
350designs

subscribing

Bevan@drupal.org - Tue, 2007-11-27 05:27

subscribing

How does it look right now?

tjholowaychuk - Tue, 2007-11-27 19:11

I have not had a chance to checkout the head of views2

I might have a look at a design too

couzinhub - Thu, 2008-01-17 19:15

Will post shortly, is it still time ?

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

I'm working on the UI right

merlinofchaos - Thu, 2008-01-17 19:36

I'm working on the UI right now, so yes there is time, but sooner is better.

You might like to demo

Bevan@drupal.org - Thu, 2008-01-17 20:53

You might like to demo webnode before getting too far into this. I think there is a lot of great UI ideas (and bad ones too) there that are useful in views' UI. I wish I had time to document them better for you.

Bevan/

My Contribution

couzinhub - Fri, 2008-01-18 03:54

Here is my contribution, the view interface would use some Jquery to display TABS that would not need to reload the page if selected, and some Ajax (I think.. I'm just a designer ;) ) similar to the password check, to display info about required fields, and if the view validate or not to be submitted.

I Designed few steps, but basicaly it would work like the original view, but each field is in a tab. If a tab is required and not filled yet, there's a red light that indicate that the user should fill it. Some light are black if the tab is not required, but would turned green too if filled correctly.

I just modified the way Page / Block are displayed, and re-united them inside one Tab. Also, I didn't designed it, but you will notice that Exposed filters is missing, it's because I was thinking that it should belong inside the FILTERS tab.

Also, very important, I use the DRAG AND DROP to reorganize fields, filters, or sort criterias...

See the previews here :

http://www.couzinhub.com/Views2-UI/Views-2-UI-1.jpg
http://www.couzinhub.com/Views2-UI/Views-2-UI-2.jpg
http://www.couzinhub.com/Views2-UI/Views-2-UI-3.jpg
http://www.couzinhub.com/Views2-UI/Views-2-UI-4.jpg
http://www.couzinhub.com/Views2-UI/Views-2-UI-5.jpg
http://www.couzinhub.com/Views2-UI/Views-2-UI-6.jpg

The Drupal Agency >> www.raincitystudios.com << WE LOVE TO BUILD
Me on the Web >> www.couzinhub.com <<

Nice!

KarenS@drupal.org - Fri, 2008-01-18 11:15

I like this one a lot. It is similar enough to the way the Views works now that it would be easy to get used to, and the tabs make it easy to see what things are done and what things still need to be filled out.

I think the views UI still

tjholowaychuk - Fri, 2008-01-18 15:19

I think the views UI still needs to stay consistent with the theme for the majority, having different tab styles just makes it stand out more in an un-attractive way IMO,

vision media
350designs

Great work Hub!

stevek@drupal.org - Fri, 2008-01-18 19:20

Morning Hub(!),

After having a day to sit on some thoughts regarding the Views UI that you posted yesterday, I thought that I'd share a couple points that should be noted. Not directed to your example exclusively, but I can't help but think of the possible problems of a user having to adapt to a new UI.. as apposed to something that's more generic and continual with other interfaces within Drupal.

I think the best way to approach a great UI design, not Views in particular, is for it to be easily adaptable with future modules. Something that's timeless and re-usable.

Notes for your design:

Validation of input fields.
- Instead of having graphical notations or icons to indicate required fields, what about defining a thick red border (or some other eye catching colour) around the input field? Personally, the red asterisks don't catch my attention enough and I sometimes overlook required fields. By removing icons, this would decrease having the need to package the module with unnecessary icons, and allow users to theme them if needed.

Drag and Drop fields
- Definitely needed. Love the implementation.

Fields tab
- Not a big deal, but something to point out. What if we had the "Add fields" reflected on both the top and bottom of the area that shows what fields are already shown. If a user has a lot of fields displayed, scrolling up and down to add fields would be a hassle. Same thing for the sort criteria "add criteria" box.

Other than that, looks great! Hopefully I can free up some time next week to help out.

Cheers!

Production Designer & Developer
Raincity Studios

Good points

couzinhub - Fri, 2008-01-18 19:52

I like the red border ideas instead of icons. Even though I don't think that people would spend time in theming the views interface, as it's only for dev/theme-crowds, it's a good idea to try to stay away from too much 'iconisation'.

About the field thing, I'm not sure.. it means that we would have 2 fields to start, and that could be confusing, but maybe instead of having the add field at the bottom, putting it on the TOP ONLY would save some time. The user would just add the fields without having to scroll down, and then re-organize them with the drag and drop function.

And Steve... stop using big fonts, I feel scared now :) !

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

Tab with red x is confusing

Solipsist@drupal.org - Fri, 2008-01-18 11:35

The tab with the red X is really confusing I think. It's better you use the Stop icon from the Tango icon collection up there as well as text saying "view not valid". That tab can very easily be confused with "delete this view" or "close screen/end editing".

Jakob Persson
Webbredaktören - www.webbredaktoren.se

I totally agree, very good point

couzinhub - Fri, 2008-01-18 16:02

I'll work on the last tab, you're right it's very confusing. Also I've noticed that the SUBMIT button is missing... I think the submit button should be under the form, but not only when the last tab is active, on all of them, so you can submit the view at any time.

About the tabs, that's a good point. I actually used the new ZEN THEME default tab, as it is the one that most of the themers use for a new website, thinking that these tabs are not too fancy and they would fit it most of the designs.

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

Views UI Status

tjholowaychuk - Fri, 2008-01-18 15:20

What is the current UI status? Im sorry for asking but I dont have time at the moment to check out the repo, but im curious where the design is at

vision media
350designs

...

alpritt - Fri, 2008-01-18 21:50

Very early stages so not much to see yet. But it's starting to get attention now, so it is progressing.

Views 2 vs Views 1

merlinofchaos - Fri, 2008-01-18 22:02

The current Views 2 UI status is ... humble beginnings. I'm trying to figure out a good way to structure the main page and then start editing all of the stuff.

I have a couple of ideas. One major problem with the most recent mockup is that it's purely a mockup of the Views 1 UI, and it doesn't take into account any of the new features from the earlier mockups. Things that the new UI must account for:

We are no longer limited to just one page and one block; there are now 'displays', and you can have 1 or more of them. Displays might be called output types or something by the end. I don't know.
A view has a 'base table' (we're calling this the view type, now). This is the table you're doing queries on, essentially. It can be things like node, user, taxonomy, comment, etc. It is set during creation and cannot be changed thereafter.
Each display can have it's own fields. It's possible that each display can also have its own arguments, sort criteria and filters as well, but this hasn't been fully decided.
Each display has a style plugin. That style plugin may have an additional row plugin, if the style plugin supports it. Each of these items can have its own settings form that is unique to that plugin. This is one of the most challenging pieces of the UI because you have several dependencies to get to unique forms.
In Views 2 the view name can't be changed once set.
There will be a new thing called relationships, which is the kind of thing that will let you view fields from related nodes. Example: I am looking at a view of albums. THe album has a nodereference to artist. This node reference defines a relationship; by activating that relationship, I can then view fields from the album OR the artist.

Right now, what I'm thinking of is starting with a summary of the entire view, and then each piece of the summary has 'edit this' links to let you go change it. We can use ajax, popups, or just go to another page to do the editing.

I have technology to edit just a piece of the view, so we can span multiple pages easily now, and we don't need to use javascript tabs to do it. I've been dithering about these tabs. However, we shouldn't use Drupal's tab system because it is a little too inflexible; I had problems with it in Panels 2 and I want to go a different direction here.

Could you elaborate this

couzinhub - Sat, 2008-01-19 00:55

Could you elaborate this :

"Each display has a style plugin. That style plugin may have an additional row plugin, if the style plugin supports it. Each of these items can have its own settings form that is unique to that plugin. This is one of the most challenging pieces of the UI because you have several dependencies to get to unique forms."

It's the only one I'm really having a hard time to understand...

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

Sure. The style plugin tells

merlinofchaos - Sat, 2008-01-19 07:12

Sure. The style plugin tells views how to style the overall list; the row plugin tells Views how to style each item within the list. Not all style plugins can have row plugins, but for those that can, they're interchangeable. i.e, I want a list view where each item is a teaser; or I want a panel view where each item is aggregated fields.

Ideas we are working on in IRC

alpritt - Fri, 2008-01-18 21:46

These are ideas we are working on in IRC now. They are very much incomplete and up in the air.

http://humte.com/files/ViewsUI.png
http://humte.com/files/ViewsUI2.png
http://humte.com/files/ViewsUI4.png

SVG version.... http://humte.com/files/viewsui2.svg

other data types?

aaron - Fri, 2008-01-18 23:07

Exciting! I noticed that Views 2 allows views based on nodes, users, comments and taxonomy. Are there hooks so that one could expose their own type of data, so it wouldn't have to be tied to nodes?

Aaron Winborn
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes

Yes indeed. And you can even

merlinofchaos - Sat, 2008-01-19 00:21

Yes indeed. And you can even use an alter hook to tell existing tables () how they relate to your base table, should that relationship exist.

That'll make Views much more useful as a generic query builder.

You just made my day! Thanks

aaron - Sat, 2008-01-19 00:37

You just made my day! Thanks for the great work you're doing! (Here comes Views RPG...)

Aaron Winborn
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes

Ok guys..

couzinhub - Sat, 2008-01-19 00:46

It's a little bit hard to follow but I think I get the general idea of the new functionnalities of views 2... I guess I should change my mockups a bit ... !

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

Some notes from IRC

yoroy - Sat, 2008-01-19 01:54

__Type > Display

The display has more to do with where the output goes than what the output is. Think of it as the portal: The 'page' display type means that it has a URL and menu possibilities. Whereas a block doesn't have any of that, but it has an interface to the block mechanism.

__Type > Display > ??

Within each display, anything that tells you how the whole of all of the records are presented is the style plugin. Anything that tells you how just one item is presented is the row plugin.

Tables don't get a row plugin because you've got to have the

table> and
tags working together right. But a list plugin is ok; you can have most anything you want inside an

tag.

Choose list format: List or Table
Configure list items: Teaser, Full, Fields

__ Type > Display > Format > Item

What do you want to display? Where do you want it displayed? How do you want the list formatted? How do you want each item styled?

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.

http://www.yoroy.com/elders/drupal/viewsui-10.png
http://www.yoroy.com/elders/drupal/viewsui-10.svg

Updated contribution

couzinhub - Sun, 2008-01-20 03:41

Hi Guys, I worked a little bit more on the UI, after thinking about all the new functions of the Views 2 module.

Few new Ideas...

First one, the ability to show/hide the descriptions. I've notice that there is a huge amount of descriptions in the view interface, and that after a while, I never read them, so they just stay in the way. Hiding the description also really clears the layout.
I separated the view list from the Filters / Relationships, as to me filters and Rel. apply to all views. I'll change that if filters can be applied to each individual view. If Filters or Rel. apply to each display, it'll make things even easier as it'll just belong to the main window as a tab.
I changed the display of the filters/fields table, and think about using jquery to show/hide the settings of each row. If not expanded, a row can still be moved around with the drag and drop function, or deleted by clicking on the icon on the right. It really help visually not having all these settings always showing up.
To add a page/bloc/rss... the menu should be on top of the list, to avoid scroll down every-time you want to add a new one.
I created a 'sidebar' that list all the view created, and identify them with icons. (page/bloc/rss...). Was thinking also that it would be nice to be able to CLONE a page or block, as there is a lot of settings for each one of them.
For the settings of each Display (page/bloc/...) I still think we should use jquery tabs to avoid reloading the page as much as possible. I also would love having green/red colors that would tell me if the Tab is filled correctly or not, and a little icon on the right that shows if the view is valid or not.

I still need some clarifications about Style plugins and Relationships to come up with a coherent UI.

Hope you like it ;) !

http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-1.jpg
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-2.gif
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-3.gif
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-4.gif
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-5.gif
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-6.gif
http://www.couzinhub.com/Views2-UI-2/Views-2-UI-2-7.gif

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

I find your wireframes

Bevan@drupal.org - Mon, 2008-01-21 01:15

I find your wireframes confusing because the user is to create 'views' while they are trying to 'Add a view'. I think the word for the inner 'view' (page, block, etc) is 'display'. Right Merlin?

I agree the red/green tabs help communicate the status / progress. But it is unconventional. I'm not sure if it's worth that trade-off.

Bevan/

Yes, 'display' is the right

alpritt - Mon, 2008-01-21 11:30

Yes, 'display' is the right word. I introduced this confusion in my mockup to see if it made things clearer for newbies. But it causes too much confusion so it was a bad idea.

Wireframes for creating a new view.

yoroy - Sun, 2008-01-20 21:48

Answer this question and you're set to start configuring a new view! Option A seems to be the favourite in IRC.

Some more important info to know:
Fields and arguments are display specific. And (for now), filters, sort criteria and relationships are global only.

A is definitely easier to

Bevan@drupal.org - Mon, 2008-01-21 01:10

A is definitely easier to understand than B. B has too many 'blanks' to be filled that it isn't easy to understand or read.

> filters, sort criteria and relationships are global only.

I can see why relationships would be global across a whole website, but not filters or sorts. Surely they either view-specific or display specific.

Bevan/

Not global across a website,

merlinofchaos - Mon, 2008-01-21 05:22

Not global across a website, but global across a view. (This matters because I've been kicking around the idea that sort criteria and filters might be specific to just a given display; so that a block might have a different filter than a page, or two versions of the same page might have different filters).

general rules, overide

couzinhub - Tue, 2008-01-22 00:24

Would it be possible to set a 'general rule' for all the display, and then being able to override them in each display if needed ?

For example, with sort criteria, I would define a general rule to sort the nodes by 'creation date'. Then if I don't specify any sort criteria for a display, it will use the general one : 'creation date'. But if I create another display, that would be a block, if I would like it to sort the nodes differently, let's say by 'last update', I could override the general setting of the view to only apply it to the specific display.. does that makes sense ?

I took the example for sort criteria, but I imagine we could think about the same system for other things like filters or else... even if I think that filters is more of a general rule only...

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

sort criteria and filters

Bevan@drupal.org - Tue, 2008-01-22 00:48

sort criteria and filters might be specific to just a given display

I don't know the details of why views now have displays, but IMHO that defeats the purpose of displays. It brings us back to the same problem we have in views1 where you need to duplicate views in order to have multiple blocks, pages or other displays.

If this level of flexibility is required at the display-level I think it makes sense to make displays to inherit it's views' sorts and filters by default, but allow displays to override them too. But I think that's a very rocky track as the difference between a display and a view is then very quickly blurred and made confusing.

Bevan/

...

yoroy - Tue, 2008-01-22 07:51

Would it be possible to set a 'general rule' for all the display, and then being able to override them in each display if needed ?

Yes, that's exactly what happens: create 1 display first, then add others that may override some of the default settings:
- Fields and arguments are display specific.
- Filters, sort criteria and relationships are global.

Displays will allow you do the things you'd create 2 almost idential views for now. Create a page with teasers and a block with specific fields for the same dataset.

I think we should map the creation of a new view as closely to the existing process: configure the view for 1 display first (creating the default settings), only after finishing that, you'll be able to add a new display and override the defaults with display-specific arguments and/or fields.

I've had plenty of use cases

catch - Tue, 2008-01-22 12:24

I've had plenty of use cases for tweaking sorts and filters for very similar views, so this would save some duplication. Having the initial sort set unless overridden elsewhere sounds sensible too.

Of all the wireframes here I

Bevan@drupal.org - Mon, 2008-01-21 01:29

Of all the wireframes here I find The first one by merlin easiest to understand: http://groups.drupal.org/files/views2-merlinsmockup.png

This is partly because it's fairly similar to views 1 and doesn't feel completely new. However that often-snubbed carry-over factor shouldn't be ignored for this UI, considering the vast majority of views 2 users will be migrating from views 1.

Having said that, there is room for improvement here and chunks missing. parts of other wireframes fill these gaps. For example, a first step is required to establish what type of view (node, user, comment) it is. Also the wireframes for the settings page / popup / thickbox for each relationship, field, filter, sort are missing.

I think the main thing I like here is that the displays are above the view-settings. An probably-good alternative to this visual separation is perhaps to have separate pages for global settings and displays, or even each display. The general rule thumb that applies here is "If you your form is too long or complicated, split into more pages".

The 2x2 layout of the global settings is possibly confusing. What about putting them in an accordion?

Bevan/

On second thoughts, I'm not

Bevan@drupal.org - Mon, 2008-01-21 01:31

On second thoughts, I'm not sure accordion is an improvement here.

I'm far more convinced that there needs to be separate urls, forms and pages for:

global settings
each display

Bevan/

I think that if we want to

couzinhub - Mon, 2008-01-21 03:20

I think that if we want to improve the UI, we need to avoid having to reload the page all the time. I've been working with views and panels a lot, and for example, I found one of the most frustating thing in both UI is that you reload the page all the time, even when you change the order of the fields or else.. it's time consuming, and totall un-productive.

Also, Views is really suffering from a huge lack of hierarchy in the presentation of the form. All the field are listed in a no-ending list and you don't see the difference between field / sort criteria / filters right away.

And we shouldn't feel like we can't change things because it's 'unconventional', especially if it's a visual help in the understanding of the process. Our only concern is to make the UI easy to use, and easy to understand, even (and especially) by users that are not used to drupal.

We should also really take advantage of all the latest technical improvement, like jquery / ajax / etc... to make the UI really interactive.

I really don't think, especially as a View user, that lots of different pages would be a good idea. Not only it would be a long process to create a view, but it would also be a drag to just access the information I want to edit. The actual view 1 UI has all the settings on one page, and I don't think that we should change that, except maybe for the introduction page where we put the information that will not be editable after creating the view.

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

And we shouldn't feel like

merlinofchaos - Mon, 2008-01-21 05:24

I disagree with this. It is important that the Views UI conform to the UI of the rest of Drupal. Views is not an application by itself, it is an application within Drupal. Drupal sets certain expectations of UI; Views must conform to them or it is a poor player in the game.

...

alpritt - Mon, 2008-01-21 12:00

"we need to avoid having to reload the page all the time"

Basically I agree. I think it is pretty obvious that it would be best to change the order of fields, etc through javascript. Dividing the page into separate URLs for each display/global settings is another question entirely. One for which I think there are both problems and benefits. If you put everything on multiple pages, you have to keep refreshing the page. Put everything on the same page, you risk succumbing to a complicated layout.

It's also worth considering this from the perspective of how each display will be accessed via local tasks.

"And we shouldn't feel like we can't change things because it's 'unconventional', especially if it's a visual help in the understanding of the process. Our only concern is to make the UI easy to use, and easy to understand, even (and especially) by users that are not used to drupal." (my emphasis)

I somewhat agree and somewhat disagree with Merlin here. Even when an application decides to use a different UI approach to everything else (for example in save dialog boxes) it is confusing because the user has to relearn the interface. So convention is really important. However, if it truly does make the interface easier to use then we shouldn't be afraid to fight convention; it would be silly not to since ease-of-use is the goal whereas following convention is a means to that goal. The way to judge is to look at the learning curve vs. the frequency of use.

Note that there is a point

merlinofchaos - Mon, 2008-01-21 16:05

Note that there is a point where fighting convention leads to massive code bloat, because we can no longer use Drupal's tools to do things. For example, those nice red-box error messages on form validation? That's all automatic. If we decide to do it differently (javascripted red tab, for example) that's a LOT of code that must be written for that feature. (Which is why I won't even consider that one).

I understand that

couzinhub - Mon, 2008-01-21 17:28

I understand that sometimes, an idea that seams easy for a designer like me might be very hard to code... In that case I totally agree that we shouldn't use a tool if it require too much code to build, and start to think about other ways to improve the IU. Maybe we should actually think about developing such tools not for views 2, but as a project in Drupal 7 UI. This way we can think about a general way to improve the UI in Drupal, and and make it available for all modules.

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

Views 2 visualisation

yoroy - Mon, 2008-01-21 09:23

This tries to visualize the hierarchy of available settings in views 2.

That's really useful. Do

Bevan@drupal.org - Mon, 2008-01-21 10:18

That's really useful. Do you think we could also see a print_r of a views object? I would expect it to be analogous to the hierarchy you have communicated, and that we need to communicate to the user.

Often the actual backend data structure has a close relationship to the UI hierarchy / layout.

Bevan/

var_export of views object

merlinofchaos - Tue, 2008-01-22 22:36