Personalisation: meta-data vs button(s) on page

Hi everyone,

Starting a new thread for this aspect of personalisation, about how the fall-back mechanism works in the SC text.

I understand from Lisa that providing the meta-data is the preferred method (the second bullet), but due to overhead there was a wish that an on-page version could conform. The recent SC text starts:

“For pages that contains interactive controls or with more then one regions, one of the following is true:


  *   a mechanism is available for personalization of content that enables the user to add symbols to interactive controls OR…”

I am not convinced this is any less work than the second bullet, so I am confused about what benefit it adds?

Assuming people don’t just do an absolute minimum, the process for both would be:


  1.  Assess your page templates against the coga-personalisation spec and work out what meta-data is suitable.

  2.  For static elements things like header/main/footer they can be added to the templates.

  3.  For dynamic elements like a CMS-driven menu this will involve a fair bit of programming. Also, if CMS users can add things to the menu it will cause a huge overhead of adding meta-data fields to menu items, AND training users to know what to do with them. (E.g. how does a press officer adding a sub-section to their news page know what to do with coga-context? Even if the answer is nothing, it is still a question that they will ask and need answered.)

  4.  Testing that if someone applies customisations the whole site doesn’t fall apart in a big mess.

  5.  Update the layout and possibly the design in order to allow for icons to be added, text to change size, backgrounds to change.

I’ve gotten to know the coga-personalisation spec and can see how some of them can be applied. I haven’t worked out the testing aspect yet and this is probably the biggest overhead.

There are too many connotations for the author side to be responsible for. Teams already spend a huge proportion of time browser-testing, (small) device testing, hopefully AT testing. This is adding another layer to the matrix, so for every connotation (icons, text size, colour scheme, hidden elements) people would have to test everything again, it is a multiplier effect where it multiplies the QA testing time needed.

It isn’t just a little bit extra, and it doesn’t matter if it is an on-page control or a user-side script, the testing should be the same in either case.

I think there are a couple of options to get around it:


  *   Have one set of criteria for people to test with (like the LVTF have been trying to do with text-adaptation). E.g. max-out the icons, text-size and show all options as the test case.
That would need to be defined now and be part of the SC text otherwise the SC is not testable.

  *   Drop the first bullet, focus the SC on applying meta-data, and don’t make it an author responsibility to test the effects of using the meta-data.

I’d opt for the second, that is the ‘something’ to get in now, and can be built on.

Cheers,

-Alastair