Site Property vs User Preference?

Site Property vs User Preference?

  

Hi,

We are working on a product (web and mobile) that can be adapted to a great extent by the end-user. From an end-user perspective, it means that they can change e.g. the line count of a list or simply change the default theme setting or set a default homepage. In the baseline product we’ll provide the default settings, but an end-user can tailor them to their needs.

The idea is when an end user adapts a default setting, we store this in a user preference entity which override the default site property value. I am worried a bit because I am expecting performance issue due to the great amount of user preference records and the preparations DB calls. 

Any thought is highly appreciated.

Thanks,

Jeff

Hi Jeff,

Would it be feasible to have a single record for all preferences, or would this become too large?

Thanks for your swift response Kilian. We identified 43 properties that could be adapted by each end-user. With an end-user base of 15K plus. Do you mean a single record for each user or just one humongous record that contains all preferences?

The latter, since it must be stored in the Local Storage. It's a bit of a trade-off between reading a lot of small records vs. reading one large one. The benefit of the latter is also that you can type the attributes right (Integer, Text etc.). But I'd advise you to do a test to see what works best for you.

I would say that you could create a preference entity with each of the properties and have one for each user. On login you could read the entity once and then save the preferences to a session variable and read from there instead of calling on every page? 

As for the defaults, you could just have one instance of the entity with UserId = NullIdentifier() and have the system default to that if the user has not specified a difference.

@Jordan,

SessionVariables aren't available for Mobile, unfortunately.

Why not read the record of the user when he/she logs in and store the value in (a) session variable(s)? 

Kilian Hekhuis wrote:

@Jordan,

SessionVariables aren't available for Mobile, unfortunately.

I did not know that! That is very interesting. Thanks Kilian.

Solution

Note that for web, using session variables may be a good idea (especially if they're small values), but for mobile, like I said, that doesn't work, and you'll need to read the pertaining settings for each screen.

Solution

Kilian Hekhuis wrote:

The latter, since it must be stored in the Local Storage. It's a bit of a trade-off between reading a lot of small records vs. reading one large one. The benefit of the latter is also that you can type the attributes right (Integer, Text etc.). But I'd advise you to do a test to see what works best for you.

I'm trying to understand what you meant with a single record? You mean using an entity or structure?


I was talking about an entity, as I assumed that's what you were talking about.

If you can use a session for web you can then use a Local Entity on mobile, so at least the calls to that are quicker than having to do a server call each time.

True, but remember that a) for web, database calls are a lot cheaper than for mobile, since lightning fast network and big-ass database server and b) session variables add to the view state of the page, making them potentially slower.

Kilian Hekhuis wrote:

I was talking about an entity, as I assumed that's what you were talking about.

We're on the same page :-)

I think this is going to be the direction for a solution: Lets assume, we create such a record for each end-user, and while the end-user logs onto the system we load and translate the record into a JSON structure which can easily be used throughout the user session or local entity for mobile. 

The only challenge we'll face, is when the end-user is changing their own preference?! But I assume we can change that user preference on the fly as well?

I'm not sure why you are translating to a JSON structure? You can continue to use the entity.

I would assume the changing of preferences is done via some preference page? You can have logic in there to store the changes. Also, for mobile you can then sync it with the backend.

Kilian Hekhuis wrote:

I would assume the changing of preferences is done via some preference page? You can have logic in there to store the changes. Also, for mobile you can then sync it with the backend.

Most of them are indeed customisable by a preference page but some are also adaptable on the fly. As an example, the line count of a entity list or the entity list order by column.