Journal CmdrTaco's Journal: CSS, Light Mode, And More 6
We knew light mode would irritate people so let me discuss it a bit here: Light Mode serves two seperate purposes: to provide a low bandwidth Slashdot for people with slow network connections, and to provide people who want a simplified design with just that.
The plan is to seperate those two tasks. The latter is simply new CSS themes targetted to a handful of common design desires. Since the site degrades relatively well, simply using "No" stylesheet actually accomplishes much of what light mode did anyway.
The bandwidth issue is trickier since it requires some actual code logic. Simple things like stripping out a lot of the menus and slashboxes that people don't need is a huge start. It's relatively simple to do but time consuming to do it right.
All of this is actually relatively minor simply because the number of people who actually use light mode number in the hundreds, and its hard to justify spending several days of work writing code to please such a small group, especially because when you get down to that level, they actually want a dozen different things. Some want "Feature Complete" and others want "Stripped Down For Handheld XXX" and others want something in the middle. Facts are we can't appeal to EVERY desire, but we sure do try where it makes sense.
The good news is that the code is in CVS, and now that we have stylesheets, a lot of things that were "Impossible" under the old code are probably just a couple lines in a custom stylesheet.
A few people asked about a redesign of Slashdot which I made mention of in the announcement yesterday. If you want to get started, the gist of it is that Yes, we will have some sort of contest. What prizes? What Rules? When? I have no idea. But if those silly little limitations don't scare you, and you want to get cracking now, let me make a few suggestions:
- The new Slashdot design will have to have all the user interface components you see today. Just because you don't like the section index or the banner ads, a winning design will still need to have them. Now you can move stuff around, or even hide some of it in roll-over menus, but the new design must retain all the links you see today.
- Design elements that ought to persist: the slashdot signature shade of green, the curve in the upper left hand corner, the caliseo font. It would have to be one hell of a design to get me to sacrifice these things which I regard as essential to Slashdot's "Look". I want a new design, but whatever is new will need to pay lip service to the original design. Some sort of visual consistency.
- The topic icons will need to be placed on white unless you plan to rebuild all of them. We don't have source material for a lot of them, and rebuilding a hundred topic icons from scratch is not likely.
- We'll want mockups of the index, an article (with comments!) and probably the user preference page.
- If you can do it entirely within CSS, that would be fantastic. Some minor code changes would be done for a fantastic design, but mostly we want skins to work entirely within a standardized css framework.
With CSS wrapping up, Slashteam is ready to take on some new projects. Pudge has been working on a new form validation system that is more extensible. This will make new forms of validation easier to add, and better error messages. Also the search system is due for a rewrite. The API is designed and the front end is mostly complete. Now its just a matter of building new guts so that it actually finds the right stories. And don't get me started on the moderation system rewrite: after a number of biz related needs (subscriber stuff and daypass advertising stuff) we're finally ready to return to the beast that is Moderation.
Blackberry Browser (Score:2)
Also, I find myself scrolling (forever) down to the Stories after passing the long first column of User/Preference/Subscribe/Sections/Help/Stories-O
It would probably benefit the Blackberry population immensely if somehow the first column were transposed to the 2nd column, and the main body were the first column.
Is this worthy of a bug report?
The trouble with the mobile devices and Light mode (Score:2)
1. The ad can add up to 30 KBs of additional downloading size. This is not only enough to run out of allowed memory on a mobile device (e.g. on a feature-phone, let alone cheaper phones), but to even crash it. That's the reality of today's mobile browsers, they suck because they are not given enough memory by the device. I understand that ads are necessary, but could you instead default to text ads for the Light mode? Also, a HUGE help would
Re:The trouble with the mobile devices and Light m (Score:2)
If all the handhelds would return something in their browser string (ie you find a commonality so the html-header;misc;default knows the user is using a handheld) then you modify the
[% css = Slash.db.getCSS() %]
[%- FOREACH file = css -%]
to instead just show the user the handheld.css && set user.mode = 'lightmode' (I don't know off the top of my head how the newer code designates the new light mode? by section? by user.value?)
Anyway, the idea then would
Re:The trouble with the mobile devices and Light m (Score:2)
They don't. Each mobile browser has its own user agent. Yes, there is the URFL (or whatever this database is called), but it's slow to process, too big, too buggy, and incomplete.
At OSNews we had to assemble our own database to deal with the probelm. It took me 2 years to gather info from 120 browsers. But the result is very good.
Re:The trouble with the mobile devices and Light m (Score:2)
Re:The trouble with the mobile devices and Light m (Score:2)
I can share up to 10 most popular mobile user agents and some basic code/explanation how it works just to get you started, but I can't do more anymore.