One of the things I've never liked about Drupal is how it handles the profile and the edit account pages.

Short version

I've created a sandbox project to start working on ideas and to solve this in D7. The whole idea consists of two simple concepts:

  • Profiles should be easier to customize/hack/change at least for themers. Even if this means starting with a blank page. Why? Because an admin could just add blocks to customize the profiles without having to remove the "History" section, the Picture and who knows how many more stuff.
  • Settings should be separated from Profiles

Extended version

Let me give you two examples of why I'm frustrated with this situation.

  • If you're trying to make a simple community site, where users visit their profiles very often, you'll probably want to theme the Profile. The problem is that the Edit Account is always right next to the Profile. Even worst, the View and Edit tabs make everything more confusing. Why is this? Because we have in one single place, the Profile, Stuff like "History", Content, Pages added with Views, and Settings.
  • Lack of consistency. If you look at the Shortcuts module you'll see it implements user/uid/shortcuts as a path. OpenID does something very similar and many other contrib modules do the same, like Notifications. The problem with this approach is that it's in the same level as the Profile (user/uid/account), when this is a configuration page and it should be under user/uid/edit/shortcuts.

Where does this come from? Well, if you visit websites like Twitter.com or Digg.com and many more you'll see that they separate the Profile from the Account Settings. Both sites, use a Tab for each group of settings so Change your password is not mixed with Change your Email like Drupal does. A long form in user/uid/edit is usually confusing.

As I mentioned above, I created a module to address this problem. What it does so far is:

  • Separate the Profile and Edit Account pages completely. The user won't see the View and Edit tabs at all.
  • Create a Settings page to handle the user settings. Account, Profile and Password have been separated into their own pages. This gives us more meaningful paths for the edit account page. Instead of having user/uid/edit/foo, the user will see settings/uid/foo
  • Provides a hook_profile_page_category() based in hook_categories() so any module can create a configuration page on its own and integrate with this module in a more consistent way.

If you have ideas or want to jump in and help shape this project, please create an issue at http://drupal.org/sandbox/lelizondo/1098228

CommentFileSizeAuthor
#2 Twitter Password Settings.png384.78 KBlelizondo
#2 Twitter Account Settings.png109.7 KBlelizondo
#2 Proposed Shortcuts Settings.png27 KBlelizondo
#2 Proposed Profile Settings.png58.76 KBlelizondo
#2 Proposed Password Settings.png28.84 KBlelizondo
#2 Proposed Account Settings.png45.07 KBlelizondo
#2 Tabs.png5.93 KBlelizondo
#2 Screen shot 2011-03-21 at 10.15.17 PM.png13.38 KBlelizondo

Comments

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

You'll want to have a look at Profile 2 module for Drupal 7 contrib. It does the separation you speak of on the API level: Profiles are their own entities, separated from Users.

lelizondo’s picture

lelizondo commented
StatusFileSize
new Current Default Profile Page.png13.38 KB
new Tabs.png5.93 KB
new Proposed Account Settings.png45.07 KB
new Proposed Password Settings.png28.84 KB
new Proposed Profile Settings.png58.76 KB
new Proposed Shortcuts Settings.png27 KB
new Twitter Account Settings.png109.7 KB
new Twitter Password Settings.png384.78 KB

I had tried the Profile2 module but is not doing what I'm talking about. I'll try to explain.

There are multiple concepts here that I should try to define to avoid confusions.

  • Profile Page: Usually the page at user/uid. It can themed and some modules expand the page by adding data to it. Theming the page is a real PITA since usually involves removing some stuff that is useless in many sites. (See screenshot Current Default Page)
  • Profile fields. This is self explanatory, any custom field like First Name, Last Name, Age, etc. Usually this is visible when visiting the Profile Page.
  • User Account Fields. We could refer this as the default user fields, Username, Password, Email, Picture, etc.
  • User Account Page. This is the page where a user edit his/her account, by default, this is user/uid/edit/account. This is extended by some modules adding more tabs to it, like user/uid/edit/Some Category

This feature request, and what I'm trying to do, is not extending fields entities to the Profile. This is a complete rewrite of how a user interacts with it's own data and change it.

I'm proposing the following:

  1. Move the User Account Page to an Account Settings page to hold all the user settings and make it consistent with all core modules so any Account User Settings have the path settings/uid/foo not user/uid/foo nor user/uid/edit/foo.
  2. Separate the Profile Page from the Account Settings page, so when you access your Profile page at user/uid you don't see those confusing View and Edit tabs (Screenshot Tabs.png).
  3. Separate into multiple tabs the Account Settings page to avoid long forms and better UX. (See the rest of the Screenshots. The Drupal examples were made using the module http://drupal.org/sandbox/lelizondo/1098228 and I also added some examples on how Twitter and many others sites handle this).
  4. Make it easier to theme the Profile Page. I understand I'm being extremist when I say that having an empty Profile Page is better than the current Profile Page, but if you want to add some blocks to the Profile page, you'll first have to remove useless stuff like the ones in the first screenshot. Doing it involves coding or Panels.

As you can see, what I'm proposing for D8 (and doing it in a module in D7) and what Profile2 is doing right now, are different things. I hope now is clearer.

lelizondo’s picture

lelizondo commented
Issue tags: +D8UX usability

Tagging this.

coderintherye’s picture

coderintherye commented

I +1 the statement "Separate User Profiles and User Settings" [in core]

If a clear plan of action comes out of this issue, I would be glad to help write/test patches. However, I will caution that given the nature of this, I would first produce some sound design docs, along with some strong reasoning why this belongs in core and not contrib, so that it has a better chance of seeing implementation in D8.

lelizondo’s picture

lelizondo commented

I posted this at the usability group precisely to do what you're saying. I would like to hear as many opinions as possible to solve this problem by creating a D7 contrib module and try to push this into core in D8.

lelizondo’s picture

lelizondo commented

I moved the sandbox to a full project http://drupal.org/project/profile_page it is stable enough to at least have a dev version.

anglo’s picture

anglo commented

To make it even more flexible and future proof

The ability for the administrator to create and edit tabs himself and choose which User Account Fields (picture, status, roles, password, language, locale etc.), Profile Fields, how many of them and in what order to put in each tab would make the User Profile Settings very flexible and future proof.

From the design point of view - make User Account Fields like Profile Fields for the user profile page? And rename the issue to "User Account Fields (subsections) like Profile Fields".

David_Rothstein’s picture

David_Rothstein commented

It seems to me like the first and most important step here might be to allow profile and account to be separated (for editing purposes)? That on its own would make core user fields a fair bit more useful, and it would allow the clutter of account settings to be under a separate tab, away from the profile.

I just posted a contrib module today that does that: http://drupal.org/project/edit_profile

This is a bit different from the original proposal here so perhaps I should file it as a separate D8 issue, but I thought I'd mention it anyway.

lelizondo’s picture

lelizondo commented

I agree, profiles (view) and account settings (edit) are different things that somehow in Drupal got together. For many sites, profiles are not even necessary, while account settings are as necessary as the user module.

A profiles module who implements fields, should be able to hook into the account settings so it's there where a user edits the account settings and the profile.

SiteMaster.ServeLime.com’s picture

SiteMaster.ServeLime.com commented
Version: 8.x-dev » 6.22

Fully agree.
Having the password fields on the same page as the other user account details causes much hassle.
Having to retype a password is definitely not user-friendly. It gets even worse when modules start adding to this page.

The Change password (http://drupal.org/project/chgpwd) module addresses this, but is in Dev status. Maybe a developer can volunteer to assist to get that module into a full 6.x release. It could then be updated for 7 and incorporated into 8.

lelizondo’s picture

lelizondo commented
Version: 6.22 » 8.x-dev

This will never get into 6.x. If we push, it might go into 8.x

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dpi’s picture

dpi
Location Perth, Australia
commented
Status: Active » Closed (duplicate)
Related issues: +#453934: Seperate account and profile fields on user edit page