Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am working on a system that connects a client to a database. I am both in control of the client (written in C#) and the database (most functionality is written in pgSQL). Users have to log in in my client, which checks the database for correct username and password.

I am now running into the problem of keeping state of the user interface of the client. Think of window positions (the client uses an MDI), UI settings, etc. To manage this, there are some possibilities:

  1. Store them on the client PC using Windows' standard settings.
  2. Store them in the database, per user.

If I would use option 1, the same settings would be used even if you log in with a different (database) user, also the settings won't be roaming. Option 2 would mean settings could be overwritten if a user is logged in on two computers simultaneously.

My question now is, what approach would be best, or at least most acceptable (least surprising) for the end user? Or is there another approach that is often used?

share|improve this question
1  
I saw that you asked this exact same question on Programmers (and was advised this might be a better place). In such a case please don't cross post. On the SE network of sites, you can flag your question for moderator attention to have it migrated to one of the other sites. –  Marjan Venema Feb 5 at 15:15
1  
From UX point it's nice to know the reasons why a user changes an interface. Researching this question could give you cues and right answer. For example, you can find it depends on screen resolution. This leads to per-device profiles. Another possible reason is task being performed. This leads to per-task profiles. And so on. –  Alexey Kolchenko Apr 6 at 17:38
    
I don't agree to your statement that with "option 1, the same settings would be used even if you log in with a different user". Since that sounds like you don't like option 1 because of this, I'd like to piont out that you can clearly implement different client profiles per database user. –  virtualnobi May 7 at 7:56
    
Similarly, if you control the database API, as you said, you can also implement a logon mechanism which can distinguish between the same user logging in from different devices. So, "Option 2 would mean settings could be overwritten" is also not necessarily so. –  virtualnobi May 7 at 7:58
    
Storing these settings per user is what you need. An ability of accessing the same settings by the same user from the another machine will be nice to have (but it actually depends on behavior of your users, so it may be not needed at all). The situation with settings override by the same user logged into an app twice could be handled: just logoff user from the old session or add some kind of "token" (session which holds the token "owns" the preferences) and pass it from one session to another on user activity (and sync settings at this time). –  alexeypegov Jun 6 at 13:20

1 Answer 1

If it takes users some effort to set up their environment, then it's best to save it on a per-user basis. That could be in the database so that it roams with the user.

What I have done in similar circumstances is to store the settings in HKCU in the Registry. This makes each user's settings personal to him, and — with Windows roaming profiles — the settings will follow him around across workstations.

If a user is logged in on two workstations, any resulting conflict is resolved by the roaming profile.

[My app didn't have a database back-end, so that wasn't an option. But why take up space in the database when this sort of thing is exactly what the Registry is for?]

share|improve this answer
    
I'd never offer the registry these days for such a case. What about Linux (on desktop and mobile), or Mac, or iP(ad|hone)? –  virtualnobi May 7 at 8:00
    
In this case, it was a corporate application in a regulated environment for which a roaming profile was provided and required by the use case. Note too that the question asks about Windows. For other environments, or a mixture of clients, storing in the database would probably be better -- although even then, Windows settings could go in the Registry and other clients in the database. –  Andrew Leach May 7 at 8:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.