On Fri, 2009-10-02 at 17:15 +0100, Martin Higham wrote:
> I have finally completed version 1 of this plugin and tidied it up so
> that others can take a look and try it. My objective with this plugin
> was to produce xhtml/mp markup for displaying StatusNet sites on low,
> medium and high end mobile phones. 

Ideally, it'd be nice to have a single mobile plugin, but I'm not
convinced that it can or should be.

So, some devices can't make use of certain features of the site, and
that's fine. It really means that those devices simply need a different
experience because of their market, bandwidth, device hardware/software
specs etc.

For the time being, I don't think it makes a whole lot of sense for a
low-end device try to experience a StatusNet site through the Web. We
have other channels (SMS, XMPP, API) that is probably better suited if
they want to get/push their status updates.

Having said that, we should write plugins that are geared towards
low/mid, and high-end devices separately. Similarly, just as WAP 2.0 is
one way of offering mobile support, someone needs to give a stab at
cHTML - which is used primarily in the Japanese market.

Instead of dumbing the experience down to the LCD (lowest common
denominator), we serve them as much capability as they can handle.

> The output from this plugin scores well on the Dot Mobi mobile ready
> tests (http://mobiready.com).

That's a really good thing and I've been also checking along with other
validators and checkers, however, it doesn't factor in the experience
that one might want to offer. See above.

> The code for the plugin can be found in my repository on gitorious in
> the 0.8.x-mobileplugin branch
> (http://gitorious.org/~martinh/statusnet/martinhs-clone/commits/0.8.x-mobileplugin).
>  This branch includes the plugin and all of the changes I had to make to the 
> StatusNet core code. Most of these changes are captured in merge request 
> #1671. My other changes are to reduce the number of list items per page to 
> reduce the page size. 

I think you've accomplished a lot with that, but, if we could modularize
that, it'd be better. I'd rather not output for the LCD (e.g., changing
forms into anchors). If we can have a plugin that does that for the
low-end devices, that's fine.

> If you take the complete tar there are some additional steps required
> to configure it
> 
> 
> 1. Add the following lines config.php to enable the plugin
>       require_once('local/xhtmlmp.php');
>       XHTMLMPoutput = new XHTMLMPoutput();

We need to bundle this up with the other StatusNet Plugins in plugins/.
See my clone/branch [1].

> 2. Copy the xhtmlmp.css file to your configured theme css folder.

Plugins' CSS can stay in their own directory as we simply need to call
them using hooks.

> 3. Enable cache-control headers in Apache for css and images by adding
> the following lines to the .htaccess file. While this isn't compulsory
> it does improve handset performance over GPRS.
> 
> 
>     <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
>     Header set Cache-Control "max-age=172800, public"
>     </FilesMatch>

Do you know why this is specific to GPRS?

> 4. Optionally change the css and small logo files. The location of the
> small logo and icons is configured at the top of the xhtmlmp.php code.
> 
> 
> This plugin is not perfect. 
> 
> 
> There are still issues with handsets that have severe memory
> limitations e.g. the Motorola V3. The page size is still too large. In
> order to reduce this further there are two changes I would like to
> see. Status Net should use relative URLs where possible. Given the
> high number of links and images within a page this will significantly
> reduce page sizes. The other is to find a way to remove line endings
> and tabs from the markup before sending to the browser. 

> While the XMLWriter indent control does this it also removes other
> characters that affect the visual look of the page.

Which ones?

> The dot mobi compliance tests clearly show room for improvement too
> although generally minor ones. The only failure in the tests is the
> use of px measures within the style sheet.

We/I can change some of the px use to % wherever we can.

> Unless you have access to many handsets I would not recommend making
> changes to the CSS file beyond colour. CSS support is the most flakey
> part of handset browser implementations. It took me several days of
> testing and changing before finding a style-sheet that worked across a
> wide range of browsers. 


> The xhtmlmp.css file has no tabs or line ends. I realise this makes it
> hard to read, but it does reduce the transmitted file size quite
> considerably. 

Cool.

> While the display attribute is not guaranteed to work on all handset
> browsers its use dramatically improves the look of the site on
> browsers that do, so I have used it sparingly.

You mean the CSS 'display' property right?

> My initial notes on the implementation can be read on the wiki
> ( http://status.net/wiki/ObservationsOnMobile ). Further notes can be
> found in the xhtmlmp.php file.

Awesome.

> While I have tested this across a number of different handsets I would
> be interested in hearing feedback from your experiences.

Can you document some of your experiences in the Wiki as well? This way,
we can archive for later. I will update the Wiki soon too.

I know I've been lagging on mobile stuff, but, right now this is my
primary task. So, can we work a bit closer in the next week or so and
dissect, combine, extend our branches wherever necessary?

[1]
http://gitorious.org/~csarven/statusnet/csarven-clone/commits/0.9.x-mobile

-Sarven

_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev

Reply via email to