Style

Style is made up of many things.

Subpages

• Wish List and Identified Problems - Look here for something to work on.
• Resources - References and reading list.
• Art - Artwork links and discussion
• User Interface Design - Discussion and definitions for UI design
• Site overall color - Explanation of how the site's color / colour should be chosen and some points on colour perception.
• Typography - Font choice, spacing and markup.
• Testing

The Project

Description

"Style" is a project concerned with how the website and other aspects of the project look, feel and function. Our aim is to produce the slickest, best looking, easy to use user experience whilst preserving all the functionality that the community puts into place. Our areas of work closely integrate with those of #Dev:

• Graphic Design
• UI Design
• Artwork
• Heuristics and Usability
• CSS / HTML

Scope

To guide the development of the site with respect to:

• Heuristics: the workflow of the site needs to be intuitive and efficient. The user should need to perform a minimum of actions to achieve each task, and the steps should be intuitive. Our task is to define these workflows, assess the performance of them on the site and direct changes accordingly.
• Appearance: the site should reach the best possible standards of visual appeal, subject to its main purpose of article presentation and peer review. Our task is to develop a set of user interface guidelines to guide developers, including placement of elements, font selection graphical styles.
• User Experience: the final arbiter of the success of our work is the community. Our task is to assess the quality of our work by monitoring the usage of website elements, studying user workflow patterns and giving the community the opportunity to give feedback on style related matters.

Basic Plan

• Site Reskin - We are now at the phase of designing / planning a reskin of the project's user interface. The implementation phase of this task will become feasible once dependencies are met:
  • The site name needs to be finalized as this could significantly impact the style of the user interface and visual appearance. A name change is potentially a direction change.
  • CSS needs to be easily edited and modified to meet the user interface specifications
  • The site needs to be able to fully and easily function without Javascript
  • Javascript components must be carefully implemented to facilitate the function of the site with graceful fallback at all times
  • Agreement on the final skin needs to be made with the PTB's of the overall project.

Members and Roles

• FrogBlast - Art / Graphics Design
• Others - if your name does not appear here, mail us: style (at) soylentnews.org

Recruiting

We are interested in people wanting to help who have skills in:

• Graphic design - for critical appraisal, or assistance in the art department.
• User interface design
• Mobile app development

Contact

style (at) soylentnews.org or '#style' on irc.soylentnews.org

Work in Progress

Handheld Devices

• Hand-held devices (eg: up to 7 inch screen device) are usually held in portrait mode for reading.
• Efficient use of space requires a single column view
• These devices, when held in the portrait orientation, are not generally suitable for extensive content creation and the UI should not be geared towards content creation
• Functionality can be curtailed for these devices to a MINIMUM NECESSARY to perform normal tasks

User interface principles:

• Consider how a device is held in a right handed person. The edges of the screen are the places where fingers can accurately pick off small items, the right side of the screen is where fingers can do common tasks without impeding visibility. At the top of the screen there is usually just enough room for a utilities bar, this should be a drag down which essentially should reveal a site-map for the mobile device.
• Do not put any buttons or functions at the bottom of the page, at most a short copyright / authorship notice or a courtesy shadow to indicate bottom of document, but nothing that can be accidentally touched to cause a navigation event.

IRC Web Interface

• Owned by: xlefay
• Information needs to be provided as to specs required and who is going to write the css/html.

General Ideas

• The web interface needs generous screen space and it may well be best to use the proposed single column user interface, ie: no left and right columns, limited functionality in a header and footer containing eg: Login/Logout option, User Prefs link, Home link. This minimalistic interface is originally intended for mobile devices where screen real estate is a premium and content must have pride of place.
• The theme should be exactly the same as of the rest of the site. The web interface itself looks fine and should be simply embedded in the standard red-banner window as currently exists, so that re-theming is trivial.
• This will require a separate perl file eg: irc.pl. It should be fairly easy to strip down the features of another similar file and include html that provides a frame which loads the web interface.
• There should be checking for javascript and a polite apology that this is required, with links to one or two suggested real IRC clients.
• Ideally the log in and username should be automated to be that of the logged in user, but the wherewithal of this is outside the scope of #style (although this is the 'feel' of look and feel).

Lynx mode

Shogun (missing, presumed having a good time) decided to create non-CSS, non-JS theme for site. It would be advantageous for some users because:

• Not all browsers support CSS at all(Lynx, w3m)
• Not all browsers support CSS correctly according to W3M standards (IE6 for example)
• Not all browsers have full implementation of "newest" version of CSS (currently it's CSS4)
• Not everyone wants to use CSS because of performance issues on slower machines (CSS is very flexible and provides a lot of complexity like CSS sided animations, alpha-transparency and other resource heavy(for old machines) effects
• Not everyone wants to use CSS beasue of potential security issues:

It is proven that CSS is Turing complete, therefor there is theoretical possibility that someone could put some rogue code(shell-code) withing CSS and inject it into memory of computer using nothing else but CSS. This AFIK have not been done yet - but I believe that in incoming years someone smart enough will be able to generate such hostile CSS.

• JavaScript implementation is usually very slow in old browsers (up to 50x slower then modern 2013 browsers). Because of that majority of scripts are simply unusable for users - being well too slow.

• Owners of old computers can't or don't want to upgrade their browsers - because of lack of RAM needed to run them. It's nearly impossible to work on computer with 256MB ram with newest[2014] versions of Firefox,Chrome or Opera - because of excessive memory usage. Funny fact is that those new browsers have superior execution speed of JavaScript - but this is ALL LOST because of overall excessive memory usage of browser.

• JavaScript libraries tends to be "big". It does matter when you are using modem or 3G capped connection(speeds in range of 64kbit/s - 128kbit/s). Process of loading some of the libraries can be as long as one minute on such connections, and often JS code taking as much as 75% of overall content on the side. Early slash-dot beta was great example of that.

• In good old days, web pages were static. You download it, and after download you plug-off your Internet cable, read the article, fill-up form, write comment, and connect back to continue minutes later without any problems. With JS - most websites force user to be permanently connected to Internet.

This is especially painful in high latency links. some scripts are tracking each click on form and transport them to server and back with new orders - this is problematic because if script requires 20 operations with server, and each operation takes 500ms - it would increase end-user lag to humongous 5s... And that is all AFTER all scripts have been downloaded. Unfortunately most modern Internet sites suffer from this - because developers does not test sites under low quality Internet links.

• Because JS on websites tend to run in unlimited loops - they consume cpu cycles ALL-THE-TIME, unlike good old plain html where after download and parsing cpu usage went to ZERO.

• Javascript is Turing Complete, therefor it is possible to write malware with it. For example in August 2013 FBI injected JavaScript based exploit into various TOR servicies.

Comment by MrBluze: Possible task list:

• There is already a minimalistic mode, simplified view etc. Have a look at it.
• There are UI problems with this mode, it contains JS!
• Need to strip the JS and replace with single page settings .. not trivial
• Need to simplify the path from setting and UNSETTING the simplified mode
• Need a way of triggering simplified mode by a URL argument
• Need to bring look/feel as close as possible to original site so there is no culture shock from switching
• Need basic navigation items to duplicate at top and bottom of pages
• Need user preferences to be complete on a single page

Related Areas

CSS Work - CSS Working group for soylentnews.org