Information Architecture for Widgets - how do I organise my content?

Question

Apologies if this should be a 'Content Strategy' question... anyway, I am involved in a project that is multi-platform and will have both mobile phone and tablet components (not identical). I will need to label my discrete content packages to specify which widget they are displayed in. I've done a little bit of homework but can't find anything explaining how this is done. My first thought is to number each individual widget in the whole system, then each content package can be allocated to the relevant widget. For example, W.001, W.002, W.003 etc. Am I on the right track? Am I missing something blindingly obvious? This is for a health intervention by the way. A mixture of medical record data, graphical data treatment and normal text.

so my query is: If I were building a IA for a website I would number my pages 1.00, 1.01, 1.02 with 1.00 being a parent page and 1.01, 1.02 as child pages and in excel have notes on the content for each of these pages. My excel structure would mirror the IA structure. Our application will have widgets for different medical conditions showing lab results. I will have a Blood Pressure widget, a Cholesterol widget, etc. These widgets will display on different screens at different times. As we collect content I need to keep track of which bits of content appear in which widget. In order to specify which widget do I just use a similar approach to web page numbering? So I'm assuming that there aren't really parent/child relationships (as the widget content is independent, it's just a design and context decision on which widget appears where and when) so my widgets would need to have individual numbers, as I mentioned before W.001, w.002 etc. I don't need help in how to arrange and allocate the actual content, I get that, it's just what labels do I use to 'signpost' where that content belongs

Answer 1

When it comes to organize stuff in meaningful chunks of information, the philosophy you are about to follow are the Principles of Grouping. In your case, making chunks of information meaningful to the end user, the similarity rule is most prominent. As this is a widget I assume that you will divide content with horizontal rules or different screens. Either way the similarity rule apply.

Even though similarity is originally based on form, one could transfer its idea to similarity in content. In your case, be it a registration form (?) contact info would be one logical, similar group to implement. Another would be type of account and preferences.

As your questions is quite vague, my answer is too. But if you edit your question and ping me (comment this question) I can specify more if you like. Happy Widgeting!

Answer 2

Irith,

This is how I understand your question:

"How do I store information in a table so I know which widget it belongs to?"

Is that correct?

If so, you're describing a simple relational database. A solution would be to have three tables:

1. Content
2. Platform list
3. Widget list

You relate a piece of Content to a value in the Platform list and the Widget list in order to make it efficient, flexible and to make lookup easiest.

The Content table has at least 4 fields:

1. A key field: this is a number or value that only ever appears once in your table. This is the Unique Identifier, or UID, of that piece of information.
2. Platform identifier: this is one of a set collection of values that you store in a separate table, which tells you what platform the content came from/goes to/whatever.
3. Widget Identifier: This tells you which widget it comes from/goes to.
4. One or more fields for your content.

I'll illustrate. Say you support iOS (1) and Android (2), and have Blood Pressure (1), Cholesterol (2) and Insulin (3) widgets. Your table might look like this:

**| UID | Platform | Widget | Content |**
  | 001 |    1     |   1    | ABCD    |
  | 002 |    2     |   3    | ACBDFD  |
  | 003 |    2     |   1    | ddrsv   | and so on.

In this example, you have three pieces of information. The first belongs to the iOS Blood Pressure widget, the second belongs to the Android Insulin widget, and the third belongs to the Android BLood Pressure widget.

If you want to, for example, load a piece of information into an Android Blood Pressure app, your query would do something like:

for a UID, if { Platform = 2 and Widget = 1}, load the Content.

So, 001 would not load, 002 would not load, 003 would load. If you want to load any Blood Pressure values, you'd just confirm

if { Widget = 1}

Then 001 and 003 would load.