My account, visual design, and more...

Hi Megan,

I'm glad you like the screens.

As for the groups concept, I'm aware of it, and have intentionally tried to move away from it. That's not to say I'll be successful with the idea, but as for now, my approach offers a bit more role building flexibility to the site owner. Therefor, if he/she thinks a user needs more or less permissions, another custom role can be created (which acts as a group basically) and that user can be assigned to that role. I favor this approach since it removes the cognitive burden from the end user of having to understand the conceptual relationship of a group with respects to a role.

Only catch is, I haven't fleshed out the idea of having users belong to multiple roles in my designs yet – but that shouldn't be too hard.

Nathan

I understand and generally agree with your point and am open to further exploration – so lets keep this topic in the air long enough to come to a resolution.

Here is the thinking that drove me toward consolidation:

a) The functionality in these areas is rather sparse. After pondering the issue, I came to believe that having separate areas would likely prove to be an annoyance to most users, since clicking on either of these links in the current system leaves much to be desired in terms of functionality. Therefor, having to go to more than one place to manage these fairly trivial tasks would likely prove to be more of a hassle than the confusion that would arise from grouping them together under an arguably imprecise title.

So, while keeping things separate may be a good "development" practice in terms of allocating proper areas that can be built up over time, mirroring that structure in the UI, particularly while the areas lack substance, may turn out to be less helpful from a "user" perspective.

b) Even though the two areas are distinct in our minds (I use "our" since I do agree with your assessment), to an end-user, they're likely to be somewhat related in that they deal with user admin "stuff".

So from that perspective, a user will likely investigate the My Account link when the desire to change system behavior arises – if no other option is presented to him or her.

c) With the dashboard, sites, widgets, and tools all having various user configuration features (site settings, options, permissions, etc.) I found it best to scale back what and how is presented to users via persistent admin links.

For example, take a look at the meta header in the Site screen. At the top, you have:

<User's Name> (Sign out) | My Account | Site Settings | Help

Adding "Preferences" to this list would likely have the reverse affect that you're hoping for – in that it might confuse users more than help them since we'd be nearing diminishing returns with information clarity.

d) This hearkens back to point (a), but many preference features are actually dispersed in other areas of the UI. For example, "Change Layout" allows users to modify colors, layout, styles, etc – all preference related notions. Having these type of preferences accessible in this direct way, rather than buried deeper in an admin-esque area of the system, will hopefully negate the need for a typical Preference link.

As for notification preferences, I have to say, I was tempted to do away with them completely in the My Account area, thinking initially that it might be best to bump them down into the tool "options" area. But I later figured that even if we did that, it might be nice to offer a consolidated view in the My Account area as well. And as an aside, there really needs to be functionality that allows users to manage these preferences at the site level, rather than across all sites.

All that said, if at some future time we build out the need for more of a robust "Preferences" UI, I don't have a problem with creating a link for it. I just don't think the current feature set warrants it.

—

What do you think?

Nathan

You got me thinking about this some more...

What about renaming the My Account link to "My Account & Preferences"?

Once either of the areas reach critical mass with functionality, we can gracefully break them off into two distinct links.

Thoughts?

Nathan

Yeah, I've been going back and forth on that tab for a while now. I must have changed it half a dozen times. The idea of breaking the templates section out is precipitated by logical assumptions (much like the one's Clay mentioned with regard to the My Account / Preferences link). I'm just not sure if most users would naturally gravitate toward templates and understand them well enough outside of the context of data/site management.

It's possible, but to your point, some more usability testing would help. The users I've put in front of it gave mixed reviews in terms of comprehension.

In part, my reasons for rolling all that stuff into the single tab with some obscure techno-savvy name was to discriminate users. Sort of like using titling as a form or progressive disclosure. "No need to go here until you've realized you need to."

To be honest though, I'm not sure I completely understand templates myself. For example, what should they include? Some people seem to think a theme should be on the list. I'm not so sure about that (especially if we're talking "theme" in uportal terms). Switching a theme tends to show-off technical muscle, but arguably does little for the user. In fact, from what I've seen, it confuses them more than anything else. Try switching the confluence theme – you'll see. The location of everything changes, and if you're not hip to using technology, you might not even know how to get back to the previous theme.

Beyond that, if the template contains widgets, layout, skin, and possibly roles and permissions – is that something (particularly the last item) that should be switchable in mid-site or should it only be permitted during the site creation process? I'm not so sure.