Home / Views for the average Joe

Views for the average Joe

The primary goal of DrupalGardens is to maximize Drupal adoption. Since Drupal adoption amongst developers is taking off like a rocket ship, we’ve focused the majority of our attention on site builders and designers. To succeed at attracting these types, Drupal—and the modules we’ve decided to include—need to be easy to use.

My latest endeavor is to simplify Views. The vast majority of Drupal sites use Views but learning it is a challenge. For designers inexperienced with Drupal (our primary target), Views is just too hard. Simple Views is closer, but unfortunately Simple Views isn’t powerful enough. This got me thinking… “why is the delta between Simple Views and Views so large?

Armed with that question, I set out to leverage the majority of the Views interface, but restrict or redesign aspects that are historically confusing, i.e., arguments, multiple display types, relationships, etc. The end result is not as powerful as Views, but is easier to use.

This is only round 2 of the designs (the first was a straight port of the existing Views interface). So, I’m wide open to suggestions. Would this work for you?

http://www.flickr.com/photos/69716653@N00/sets/72157624486332877/

Reacties

Posted on by redndahead (niet gecontroleerd).

For a while I've been thinking about trying to get views slideshow to work with simple views. I like the idea of taking simple views and adding a few extra options especially the ability to choose styles.

Your design looks really simple and I think you are striking a good balance. On first glance http://www.flickr.com/pho tos/69716653@N00/4841846244/sizes/l/in/set-72157624486332877/ Makes me think that I can drag a field into one of those areas, filters/Sorts. Which I think would be nice. Overall I like it.

Posted on by Jay Batson.

The UI is highly wizard-like in the sense that I was only doing one thing, then the next, then the next.

This eliminates one big problem with Views: Where to start, and what to do!

And overall, I like where you're going. But there are two things that troubled me about this design iteration:
- While very-wizardish makes sense the first time you want to do something, once you've acquired an understanding of what you're doing this interface might start to seem too cumbersome, and become tiresome / tedious / frustrating.
- In this use case (building a view), there are LOTS of individual steps; I kind of lost track of where I was in the process of building the view.

Both of these seem to suggest a slight increase in the density of work done in each step. Thoughts?

Posted on by Bojhan (niet gecontroleerd).

I would love to review this, but flickr is making it a bit diffcult for me - constant disconnects. Got any zip file somewhere ? Delete this comment - when there is a url or something.

Posted on by Eaton (niet gecontroleerd).

Jeff,

Pretty slick work! Your concept posts at http://groups.drupal.org/no de/83924 are also very interesting. One of the questions you were mulling -- why the delta between Views and SimpleViews is so great -- can be traced directly to SimpleViews' original design for the Buzzr project. Its intent isn't to create a simpler version of the Views UI (despite its name) but to provide common listing pages with some convenient settings options, and punt the heavy lifting work to Views. That's one of the reasons that I've resisted adding more flexibility to SimpleViews: its intent is to focus doing a couple of very common tasks very easily.

I think there's definitely room for a middle ground, and the SimpleViews model -- providing a custom UI, and using it to drive the exposure of Default Views -- is something that can be leveraged really effectively by tools like the one you're describing. It's similar to the approach that modules like Calendar, where building a complex view from scratch gets painful.

Jay Batson's comments about the dangers of Wizards are important to consider: although they look great during demos and walkthroughs they can become frustrating for users once they grasp the models for what they're doing, and want to cruise through the steps quickly. But, if we're all using Views as the backend that becomes less of a problem! The useful wizard can be used for the first-pass, while the full Views UI can be used when they want to shed the training wheels. Looking forward to seeing your work progress!

Posted on by IceCreamYou (niet gecontroleerd).

Yep, assuming this is going to be used in Drupal Gardens, it would be nice if users could toggle which interface they could use so they could switch to a faster one when they get used to using it. Because there are definitely a *lot* of steps in this UI.

Posted on by Jeff Noyes.

All of this is a veneer to the actual Views. Said differently, the output of this version of views would create an entry in the list of views at admin/structure/views. When I present the list of views in this UI, i also provide a link to the actual Views UI.

Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com

Posted on by drupaltronic (niet gecontroleerd).

Really nice ! This is very slick, but too many steps I think... One thing : The average Joe (specially in non-English speaking countries) would prefer words like 'article' instead of 'nodes'.

Posted on by Heather James.

I think it would be useful to look at where the target audience is coming from.

I was speaking with an instructor who recently taught Views to a group of old-school DBAs. They were like "AWESOME!" and got Views immediately, and were saying "This is great! I don't have to write this by hand!" The average Site Builder doesn't realize the word Views itself comes from database administration, and it rings no bells.

I think a design for a "simplified" version of the functionality Views offers needs to relate more closely to metaphors and functionality the target audience are familiar with. Then- ensure the new terms they see are practical and learnable.

I don't know what their background is myself- but it might involve looking at the lowest common denominators, and UIs the typical users are already familiar with. For example the "Smart playlist" options in iTunes are a good example of limiting a result set:
http://skitch.com/heatherjames/dxnfb/smart-playlist-limit-result -set

Narrowing the result set, and controlling how these appear are two different activities, and likely don't need to be managed in the same state of the UI. The display control can relate more closely to the client: the browser, the web page, etc. This is where the drag and drop WYSIWYG tools are helpful.

To me the sketches still look like too much candy. All good, but too much at once. Prep the result set, then let's talk about how it looks. Do we need to see the website while we analyze our content?

As with the terms used... To the Site builder, the notion of "simple views" might make no sense at all, and is meaningless out of the Drupal context. On the otherhand the use of the word "query" is different. While it my be an unfamiliar term, it's transferable and a learn-able concept. Displays is also a good term- because it relates to what it does.

Not to say the tool needs to be dumbed down- users are more than capable of learning the concept. However the UI can look and feel more friendly by starting at what people know -- > and then bring them into what they don't know.

I'd defer to Jeff Eaton's warnings about "dangers of Wizards"- since Buzzr uses them. It's a delicate balance between holding someone back or guiding then through. But I think breaking up the task into clearly defined stages would help: limit result set first, then control display.

Guess how often to Drupal instructors advise people to start on the "Right side" of the Views 2 interface? Likely, they all start this way. Filter first, then talk displays.

Heather James
Acquia Client Advisory Team

Posted on by Jeff Noyes.

I love the idea of a smart playlist. Unfortunately, such an idea doesn't allow you to configure things that have been added. For example adding custom titles to fields or making the field link to its original node.

Given the complexity of Views, our primary goal was to leverage as much of the existing Views UI and power as possible, but make building and previewing easier.

Thanks so much for the idea though.

Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com

Posted on by mlangfeld (niet gecontroleerd).

I love the idea. Like a Theme Builder for data. I like the visual approach, and think it would help us visual people (designers) understand what Views is doing, seeing the effect of each step of the way. I also think that a choice between the wizard (or Views Builder or Data Display Builder) and a quicker, non-visual way would be good, offering the choice to turn off the wizard once you understand the underlying process.

So Heather, yes, I'd love to see the effect of each decision I make (at least while I'm learning). I'd really learn what each choice is doing that way. When I look at the full version of Views, I try things, but have no idea what's going to happen with arguments, some of the filter choices, etc. Visual response would be great.

Might also be a great idea to be able to name, save and reuse a view (or data display) once you've developed it, so it could be reused without going through all the steps again. Like naming and saving a custom theme.

As a designer who understands a lot of Drupal concepts but isn't a programmer or themer, I'd be happy to help test whenever you need a guinea pig. Heather knows where to find me. :)

Best, Marilyn

Posted on by Jeff Noyes.

Thanks, I may take you up on that.

Regards,
Jeff

Posted on by wmostrey (niet gecontroleerd).

I like views just the way it is but just to inform you: there's someone working on a simplified views ui as part of the Google Summer Of Code: Views Shaman. Maybe someone you want to get in contact with.