Personalized Dashboard: Widgets & Modules

13 Jan 2011 - 5:02pm
3 years ago
3 replies
1488 reads
eriklevitch
2008

All -

I am designing a portal that allows the user to add mutiple widgets/modules to their personalized dashboard. I've done extensive user research, but I am unsure if the widgets/modules should be pre-populated with data. The argument against this is the widgets/modules are highly customizable to the point where it is hard to predict what a particular user type needs in each widget/module.

In this instance, is it a good practice to keep these widgets/modules as 'empty' until the user actucally adds content to them? Or would it be better to start them off with some content even if it doesn't directly apply to their immediate needs?

Thanks for your input,

E

Comments

13 Jan 2011 - 6:13pm
Joe Ortenzi
2008

An interesting reasearch location fopr you might be something like NetVibes. they have something a little like what you describing. Or another model might be how widgets are selected and edited in WordPress.

In each of these examples, the "widgets" are of a type, to satisfy a specified but general task. for example in Net Vibes case, to load and display an RSS or site feed. They have categories of widgets, so that each customisdation is not too extreme.

It might be better to create separate sets of widgets, with fewer options each, to mimimise the amount of customisations possible, and simplifying the experience and reduce complexity overload.

16 Jan 2011 - 7:02pm
AK
2010

We had a similar situation with an web app. We didn't want to have to train the users on all the different portlets and their features so we implemented a "suggested layout". The user will log in and they are presented with preconfigured dashboards. We chose these dashboards by looking at their relationship with the client (or in more UX speak, their personas) and suggested a configuration for them.

We did the setup for them so they didn't have to.

17 Jan 2011 - 4:37am
milan
2005

Another opt for the predefined configuration and data. In a similar setting we discovered that this significantly lowers the barrier to use it, also in a personalised way, for different reasons:

* the example data shows you what the element is about without explanation
* you can use it without further configuration and it might serve you well
* it provides a trigger to go ahead and say "this is not *exactly* what I wanted but close to it" - and to create a custom version

Crucial for this is a wise selection of initial content (should be relevant to as many people as possible and easy to grasp), and making the configuration/customisation options very visible (like, "this is not what you need? click here!") - and of course somewhat easy to use.

Milan

Syndicate content Get the feed