Storing and Managing the Data

Users’ preferences need to be stored permanently, in a reliable mechanism that allows for fast retrieval and which are easily accessible by the Prioritisation engine. In addition, we need to store the user ID and device ID for a browsing session. Three approaches were considered and examined in detail. User preferences could be stored in cookies, session variables, or in databases.

We chose a relational database to store and manage users’ preferences and profiles. This approach allows the preferences to be stored permanently and offers a reliable and flexible storage mechanism. A database offers flexibility and scalibilty in terms of adding and managing records for a large number of users. A database also offers flexibility in changing attributes and their values. Managing changes to users’ preferences are easy. In addition, storing users’ profiles and preferences in a database allows users to access the page from any device (and still able to get their prefrences) without having to set preferences for the new device.

The two other approaches, using cookies and session variables, were considered but were rejected. Cookies stored in a user device need to be sent to the web server every time the device accesses the page. Thus, storing many preferences in them could waste bandwidth. Most mobiles have cookie size limits, so storing all a user’s preferences in cookies may not be possible. Storing preferences in cookies is not suitable for mobile devices with limited memory or processing power, which may not support cookies or only support limited numbers. However, storing preferences in cookies could work with desktop browsers but would not provide the require flexibility. Cookies have a 4 kB limit on desktops.

The other approach to storing user preferences would be to use session variables. Sessions are stored on the server and users or clients cannot modify them. Sessions use a small cookie to provide a unique identifier for each client. Most mobiles will be able to store these small cookies. Preferences stored in sessions, however, are not persistent so the preferences would be unavailable once the session is terminated or expired, or when the cookie that holds the session id is deleted from the client browser.

61 Having decided to use a database for storing user preferences we designed one which consists of six tables as illustrated in Figure 5.3.

Pages - Stores a unique page name and its associated pageID assigned by the database for every page. The page name is the name of each base page, for example, home.php or about.php identified through the URL variable passed to the prioritisation system.

As well as the page name, the absolute or relative URL could also be stored and must be unique. Storing the absolute or relative URL might cause issues when the directory or folder in which the page is located is modified.

Items – Stores the itemID, pageID, and elementID for each item (div) that is prioritisable. The elementID is the value of the attribute id for a prioritisable div. The itemID is an ID given to a unique combination of elementID and pageID. For a page to conform to the (X)HTML specification, the elementID must be unique in the page (W3C, 1999a). However, multiple pages might use the same elementID. For example, page Home and page About might both have element ID with value ‘Search-Find’ but with the item ID set to 1 and 17 respectively as illustrated in Figure 5.4.

Figure 5.3 Database diagram illustrating tables used to store details required for the prioritisation

62

Preferences - Stores the preference for specific items for a particular user on a particular device. It also stores the default preferences for each type of device available in the Devices table. Figure 5.5 illustrates some typical data in the Preferences table.

The Preferences table above shows that User 2 ranked item with itemID 1 as 2 for his mobile (deviceID = 2), and User 3 ranked the same item as 1 for her mobile. Rank is the priority values starting from 1 indicating the highest priority. Multiple items could have the same priority value, in which they will be displayed according to the order they appear in the initial HTML tree.

Users - Stores a unique user ID for a username and a password for each user. A userID of 1 is used for default users - unregistered (or guest) users.

The same elementID for page 1 and 2 but with different itemID • • •

Figure 5.4 Items table

User 2’s preferences for item 1 and 2 User 3’s preferences for item 1 and 2

63

Devices - Stores a device type and a device ID for each type of device. For example, the device type could be a desktop, tablet, iPhone, or mobile phone. This design allows for new type ofdevices to be added as they enter the market.

Cutoff - Stores the number of maximum preference value for a specific user on a particular device. As discussed in Section 4.5.2, only items with the preferences less than or equal to the cuttoff will be displayed in the prioritised page, items with preferences (or rank) greater than the cutoff will be removed on the prioritised page.

Example of User Preferences

Users can specify different preferences for different devices with different cutoff numbers. Figure 5.6 shows that User 3 has specified the same preferences for device 2 and 3 but different cutoff values. User 3 will get only the items in the solid-border red rectangles when accessing the page on device 2 with the cutoff set to 3. In contrast, User 3 will have all the items (item 1-9 in the dashed-border rectangle) displayed on the device when accessing the page on device 3 with the cutoff set to 4.