PDS UI

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Navigational Structure

For 2.0M2 we plan the following structure:

• Connections (home page)
• All About Me - cross-connection view of all of the user's data
• Settings - Login/out, preferences, etc.

Connections

This page shows:

• A list of connections that you have (e.g. to websites)
• There's an "Add Connection" button/link to the "Add Connections" page

Add Connections Page

This page shows a list of connections that you can add.

The list is populated by retrieving a list of all "connection"-type templates (see ConnectionTemplate in Template vocabulary) minus any connections that the user already has. The proxy:domain attribute of the ConnectionTemplate identifies the connection that the template describes.

When you click on one the add connection wizard begins.

Add Connection Wizard

What the add connection wizard does is dependent on the nature and capabilities of its template.

Every ConnectionTemplate must have the following attributes:

• proxy:displayName (e.g. "New York Times")
• proxy:class (e.g. proxy:WebLogin)
• proxy:connectionType (e.g. "business")
• proxy:externalResource (e.g. "http://nytimes.com")
• proxy:domain (e.g. "nytimes.com")

It should also have:

• proxy:description (e.g. "A world class news site with all the news that's fit to print")

The above information allows the add connection wizard to display helpful information

Each connection template may have one, two or more of the following capabilities:

• Login-capable
• Register-capable
• Subscription-capable
• ChangeEmail-capable
• DataSync-capable

We now describe these capabilities in turn.

Login-capable connection

A login-capable connection enables the user to:

• Log in to the site
• Log out of the site
• Navigate to a connection details page that shows:
  • header: human-friendly name of connection, its category and optionally: an image and short description
  • username - non-editable
  • password - non-editable

It MUST have a app-data:WebsiteFacade instance with these three scripts:

• app-data:isLoggedIn
• app-data:Login
• app-data:Logout

Register-capable connection

A register-capable connection enables the user to:

• Automatically register a new account with the site
• Navigate to a connection details page that shows:
  • The information in a login connection
  • A list of editable fields --the fields required for registering

It MUST have the scripts of a login connection plus an app-data:Register script.

Subscription-capable connection

An subscription-capable connection enables the user to:

• Subscribe to, or unsubscribe from, the email mailing list of the site

It MUST have these scripts:

• app-data:Subscribe
• app-data:Unsubscribe

ChangeEmail-capable connection

A redirect-capable connection enables the user to:

• Change the current email address the site is using to send emails to the user

It MUST have the scripts of a login-capable connection plus:

• app-data:ChangeEmail

DataSync-capable connection

A datasync-capable connection enables the user to:

• Edit a set of attributes about that user's account at the site on the connection details page of the portal
• Fill login and other forms on the site
• Scrape login, and other forms on the site

It MUST have the scripts of a register-capable connection plus:

• app-data:Fill
• app-data:Scrape

Hierarchy of connection capabilities

• DataSync > Register > Login

How is a connection represented?

A connection is represented as an instance of proxy:Connection (or subclass, usually proxy:WebLogin) that lives in the user's root context. See Proxy vocabulary for more about proxies. Each WebLogin has a proxy:domain attribute that indicates the domain of this connection. The proxy:domain value uniquely identifies this connection. If the user has a proxy for a domain (e.g. nytimes.com) then the user is considered to have a connection to nytimes.com.

All About Me

Categories of attributes:

1. Login
2. Purchases
3. Points & Awards
4. Interested In
5. Payment
6. Profile
7. Education
8. Professional
9. Family
10. Contact
11. Notifications
12. Affiliations
13. Travel

Email, Address and Telephone Labels

The PDS data model has these three sources of data related to email, address and telephone labels:

1. Observing what values the user has provided when asked questions within a specific "connection" context (i.e. the context of an interaction with an external website). For example if the user was asked for a "home" telephone number or a "work" email or a "shipping" address.
2. Explicit action by the user to select one of the built-in labels (e.g. Mobile, Billing, Home etc.)
3. Explicit action by the user to define & select a custom label (e.g. "iPhone")

Explicit actions (#2 or #3 above) override the observation (#1).

The algorithm to choose a label value to display is:

• If attribute (tel, email, adr) has user-defined "custom" label (p:label) then
  • Display the custom label
• ElseIf it has a subclass of generic class (generic class is vcard:Tel, vcard:Internet, card:Address) then
  • Display that class's skos:prefLabel
• Else
  • Look at how the attribute has been used WRT p:Home and p:Work roles and force the label to be Work or Home (pick Home if it has been used in both Work and Home roles)
• EndIf

Email labels

The first 3 below are new vcard:Internet subclasses defined in the Persona vocabulary. The last is the value of a p:label attribute also from the Persona vocabulary.

• Personal
• Work
• PDS
• (Custom)

Address labels

The first 4 below are modeled as a subset of standard vcard:Address subclasses (e.g. vcard:Home). The fifth is a new vcard:Address subclass defined in the Persona vocabulary. The last is the value of a p:label attribute also from the Persona vocabulary.

• Home
• Work
• Shipping
• Billing
• Birth
• (Custom)

Telephone labels

The first 5 below are modeled as vcard:Tel subclasses. The last is the value of a p:label attribute from the Persona vocabulary.

• Home
• Work
• Mobile
• Fax
• Pager
• (Custom)