1

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?

Improve this question
5
  • 5
    I saw that you asked this exact same question on Software Engineering (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
    Commented Feb 5, 2014 at 15:15
  • 4
    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
    Commented Apr 6, 2014 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
    Commented May 7, 2014 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
    Commented May 7, 2014 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
    Commented Jun 6, 2014 at 13:20

3 Answers 3

Reset to default
1

You could have two sets of data - one for environmental variables that are specific to the system that the user is on (window positions, visible palettes, etc) and another for settings that are more global (interface colour settings, font settings, etc)

If the systems can be used by the same user on different systems (desktop, laptop, tablet, etc) then storing things like window positions in your database could cause problems for the user - if they set up their ideal layout on a large screen and then log in on a smaller one then the window positions will be useless.

However, If the user sets a certain colour palette (perhaps because they are colour blind) then they won't want to redefine that profile every time they switch screens.

So, I would recommend storing variables that are specific to the local environment in the local storage and variables that are more globally relevant in the database.

Improve this answer
0

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?]

Improve this answer
2
  • 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
    Commented May 7, 2014 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
    Commented May 7, 2014 at 8:19
0

You also could:

  • Save on the PC for every user (and a clean up if the account is not used for X time).
  • Save on the database, but with a config entry for every PC (again, cleaning old PCs).

So you have:

  • Alice, at PC #1
  • Alice, at PC #2
  • Bob, at PC #2
  • Bob, at PC #4
  • …
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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