I present this skin as an optional alternative display. The columnising code isn't used on mobile, so this should pose no problems to small screens, however the flow between articles may be better suited to tap interfaces.
This isn't a usecase, but a list in English of required behaviour.
- Infinite scroll: Render a vertical strip of all the resources the user can see in a single list. Examples 1 2 3 4 and a big list here
- Allow them to mouse gesture up and down to past or future resources. This should add resources before they get to any extreme. The equivalent for tap interfaces.
- Work out some type of sort on the resources, so the previous sentence makes sense (as I update the resources, creation date will make more sense than last edit date).
- Add a “jump next”, “jump previous” buttons every so often (mostly for longer resources).
- If its possible to add this feature via third party OSS code into iceline, use it.
- Generate a sort concept for the resources as a single set.
- The content is to be laid out in a long strip. The content should be much longer than the viewport.
- Resources are accessed by scrolling in either vertical direction.
- The initial skin should load a few resources, and have the viewport on the middle of the co-ordinate space.
- As the users moves the viewport towards an extreme of the coordinate space, add further resources, making the coordinate space bigger.
- If the user “scrolls off the end” of the ordered resources, start adding them the other end and allow to keep scrolling.
- The extra content resources should be injected by some type of AJAH type mechanism (not a page refresh).
- The URL access point for the extra resources will need to not process the “frame” declaration. It should return the content in the named file. See render-source for a reference.
- The scroll effects will need to be tested on alot of mobiles.
Why is infinite scroll good? In the examples listed in the top, it is beneficial as it avoids asset loading time on attached assets (normally adverts). Infinite scrolling is simpler to steer for mobile. This interface will need to be available, but not compulsory. It must degrade usefully in a noscript situation.
On my test machine, the resources are acquired from the server in about 200ms (ignoring the linked resources which would be loaded once). This means it should be a reasonable speed. I will need to test this access approach on phones.
The scrolling should be vertical as matches the normal window furniture, and as our writing is left to right, this works better graphically. On a algorithm basis, it could be in either direction. Scrolling in games is free in either direction.
As this is based on the idea of serendipity, there is no direct access to each article with this interface. To enable users to see what they are reading better, I will need to add a tag to each of the resources.
A long time ago, I wrote some HTML generation code, which auto-generated TOC, and formatted page headers. The headers and the top of document had anchor labels, and each section included anchors to jump to relevant points in the document. The longer pages using a scroll concept (aimed at mobile) are now bringing back this idea.
When I created the template for the previous skin, I rearranged the content to ensure everything was “on my screen”. This one is business standard 1280x1024 ratio. The vertical access is more important than the horizontal, as there is more screen furniture on the vertical, and its numerically smaller. Therefore I squashed everything vertically where possible. For a vertical scroll this will need to be undone.
The columnisation will need to be suppressed in some fashion. If the combined resource is re-columnised everytime more content is injected; it will run very slowly.