ClientSideCust
From MashupCamp
[edit]
ClientSideCustomization
We had a discussion where a number of viewpoints were discussed around changing content at the client. Our agenda for discussion.
- Why are you interested in “ClientSideCustomization” and what does it mean to you?
- What are the alternatives?
- What could be done?
The following is a re-telling of the topics raised without much analysis, or editing for flow in telling a more coherent story. That being said, the points discussed included:
- An initial scope for topic was set as: Repurpose look, feel, and behavior of interactive content after it has been provided: using content that was authored with one set of behaviors in mind, and doing something quite different.
- An example from an Interactive Digital Bulletin Board was presented that pre-dated scripting extension like greasemonkey (e.g., greasemonkey.mozdev.org).
- One aspect of the experience of content is being able to take content offline and interact with it. In this regard, Commendo Voyager was mentioned in this regard (www.commendo.com/)
- How can one collect content and re-distribute it, much as we are seeing in iTumes and playlists.
- Regarding the ‘why client side’ issue: client side is easier – you don’t need to set up hosting, deal with accessibility, you can do it on one machine.
- There is a spectrum to client side processing, starting with user defined style sheets for look and feel customization, and proceeding to behavior modifications allowed by greasemonkey and platypus (discussed as a more ‘programming by demonstration’ approach in which manipulations on a presentation are recorded and the necessary scripts for the customization are generated).
- On the browser side, you act as one IP in accessing a site. You have the browser’s priveleges for accessing information, so that for example at the browser you can pull in information from the internet, but then combine that with intranet content available to that IP.
- A server that scrapes a site such as eBay or IMDB can be detected and blocked, but a client side scraping application acts much like any browser which has a valid reason to access that content.
- A barrier to entry to customization is the ease by which such customization can be done. For example, programming by demonstration allows people to build more.
- Alternative client-side methods mentioned include bookmarklets, customization in Flock (a Mozilla-based browser), use of cookies to store preference data.
- More generally, Anders I. Mørch describes customization as part of systems tailoring, including selection of predefined options on through extensions of systems with new code (http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=287900).
- People are getting more savvy about programming and modifications of systems through programming. Nevertheless, there is still a high bar to customization in understanding the constructs and conduct of programming. Many will write HTML, and we quite often find people doing this in the context of ‘cut and paste’: I take your HTML, copy it and tweak. There is a mentality of ‘programming by google’ (query for similar code and hack it into shape).
- Code on the client side can be more open. Much mashup code is closed source – hidden on servers, whereas client code is visible. Visibility does not imply the programming logic is practically accessible. For example, Javascript on google pages are largely indecipherable. There is a good reason for this – Google Web Toolkit autogenerates the Javascript from architected, well supported and maintained Java code.
- Limits to the Client Side include:
- Cross platform development and portability – what scripts work on Firefox might not be so easily ported to Internet Explorer.
- Security restrictions – Flash has security restrictions. Javascript can only easily access content from the server they were served from. How do we create a standard by which access across domains may be made? MySpace is a ‘walled community’ that restricts what you can do with Javascript. Some companies restrict what PCs may access the internet – what does this mean for the relevance of customization in that environment?
- Persistence of customization: Javascript and Document Object Model customizations are lost when the browser context for a page is lost, require the customization to be reapplied/rebuilt.
- Maintainability – greasemonkey scripts are not automatically updated when there is a need for change. If a system has been personalized, how can a service organization maintain that system in light of the personalizations?
- Customization is not just personal, but may occur at the organizational level.
- Customization arise not just from personal preference, but also the needs of the computing context, such as customizing content for mobile devices and use.
- A study indicated that only a small percentage of people actually bothered to customize Microsoft applications, even though the capability is there. What does this say about the relevance of client side customization – are we drinking our own Koolaid here? Note however, that a small number might customize, but is that then shared with others (e.g., templates in organizational repositories). Note also that it is a real pain to customize Microsoft applications. Is this a barrier to entry? Compare this to Firefox extensions – there is a list of hundred available. They are installed by a click. You can back out the changes – changes are reversible.
- There is a progression here in recent practice. In bloggin, people want their voice to be heard. What if you can customize on you client, but then share that back out. Can we create a community of practice around this through a re-publishing mindset (e.g. playlists)? Redistributed customizations allow one to share a user experience, not just content sharing as in blogs.This is a logical extension of the content sharing seen in blogs.
- del.icio.us share experience URL by URL, blogs share by content.
- Open Question: How do make such redistributions of experience more accessible? There are restrictions on use of APIs and content provided by APIs. RSS feed allow distribution of content – but it is unidirectional. In such redistribution, how to we share all the dependency that any customization relies on – there is an accumulation of dependency. Linux package management is complicated?
- How do we debug customization?
- How share these?
- How are the norms and practices formed around this activity?
- Further discussion in a follow-on session is planned for Thursday of Mashup Camp 2
