Journal Just Some Guy's Journal: Tuning Slashdot, part 1: Relationship CSS 11
Refactoring relationships
Right now, relationships are embedded into the comments section of story pages with tags like:
<span class="zooicon"><a href="//science.slashdot.org/zoo.pl?op=check&uid=198669"><img src="//images.slashdot.org/fof.gif" alt="Friend of a Friend" title="Friend of a Friend"></a></span>
This is ugly for a few reasons. First, it's a mess. Second, it means that every visitor has to have their own custom-rendered comments sections so you can't apply aggressive caching to the page-generation code. I would replace this with per-user CSS.
First, create a CSS file for each user like this:
/* Default class */
a.relationship {
background: url(neutral.gif);
width: 12px;
height: 12px;
display: inline-block;
text-decoration: none;
}
/* User-specific values start here: */
/* Friends */
a.user3352,a.user42 { background: url(friend.gif); }
/* Foes */
a.user666 { background: url(foe.gif); }
Next, replace the HTML in the comments section with generic relationship information such as:
<link rel="stylesheet" type="text/css" href="relationships.css">
[...]
<p>by neutral (1234) <a href="bar" class="user1234 relationship"> </a> on 2008-01-20</p>
<p>by Just Some Guy (3352) <a href="bar" class="user3352 relationship"> </a> on 2008-01-20</p>
<p>by foe (666) <a href="bar" class="user666 relationship"> </a> on 2008-01-20</p>
All "a" tags with the "relationship" class get the default CSS values. If there is also a corresponding "user*" selector in the visitor's stylesheet, then the values in that selector override the defaults. For a sad user with no friends, this means that everyone gets the neutral.gif icon. As that user accumulates more specific relationships, those CSS definitions are applied instead.
This benefits Slashdot because suddenly they don't have to generate a brand new comments section for every visitor. The per-user CSS would also be extremely simple to generate. In any case, it would be no more difficult than the current method of embedding all that information directly into the comments section.
Finally, those CSS files could also be cached very easily. Since they would only change whenever a user's relationships are modified, Slashdot would no longer have to query that information every single time it creates a page.
There are two drawbacks to this idea. First, there are no more alt attributes on images, so users don't see a "Friend" popup if they hover over the relationship button. If that's a problem, replace the icons with little smiley or frowny faces as appropriate. Second, it would take slightly more work to support putting users in multiple categories at the same time ("Friend" + "Freak"). The fix is to create a whole set of graphics like "friend_freak.gif" and "foe_friendoffriend.gif" and corresponding CSS classes. There aren't that many categories, though, so it would require only minimal extra work to cover every possible combination.
How 'bout it, Taco - could you use something like that? Less code, less bandwidth, and less processing should be pretty easily reachable goals.
Devil's Advocate (Score:2)
How easy would this be to implement considering the website is primarily database driven? I would think that all of that info is tied into the page request (given the tech discussion of October 2007 and given that I haven't had lunch yet, so my brain is a little weak
Also, since you are talking about rebuilding the way pages are loaded, would this break functionality with closed discussions, or are those static once they are closed?
What kind of down tim
Re: (Score:2)
How easy would this be to implement considering the website is primarily database driven? I would think that all of that info is tied into the page request (given the tech discussion of October 2007 and given that I haven't had lunch yet, so my brain is a little weak ... damn sugar)
Trivially easy. Right now, today, whenever a visitor loads a story, Slash has to build a set of that visitor's relationships. For each comment in the story, it checks to see if the poster has a relationship to the visitor. If they do then it displays the appropriate image. It would almost certainly be much easier to write a script to take that information and write it out as a flat-text file (conveniently formatted as CSS definitions).
Also, since you are talking about rebuilding the way pages are loaded, would this break functionality with closed discussions, or are those static once they are closed?
Actually, I'm not really advocating that (at least not yet). St
Re: (Score:1)
Have you written a sample page that allows me to add, move, or remove a friend/foe? I think that would be the best proof of concept, to help that part of the project along.
No, because the end user interface wouldn't change at all. It would still look and work exactly the same. The only difference would be a simplified and easier to tweak infrastructure.
The biggest question in my mind would be how best to generate the CSS. Do you cache the CSS for every user in advance? Create it on-the-fly and cache the results? The latter would probably be the easiest and just as quick. Set a lifetime on each file so that you don't get clogged with cached files from people who haven't visited in a year. Delete a cached file whenever someone edits a relationship that affects it. I don't think any part of it would be too challenging.
Okay, Guilty. I thought faster than I typed.
My thinking was that this part of the UI might be the more challenging part, and you need a pretty thorough script to manipulate that users lists. The reason why I think it might be difficult to write the script is because you're moving parts of the file around, not necessarily tags within an INI. But then again, I've never tried to write a file parser to move names like what you're describing, so I can't say how difficult it is. The script might be trivial
Re: (Score:2)
My thinking was that this part of the UI might be the more challenging part, and you need a pretty thorough script to manipulate that users lists. The reason why I think it might be difficult to write the script is because you're moving parts of the file around, not necessarily tags within an INI.
There would be no text file manipulation whatsoever. Right now the page rendering code looks like:
The new code would look like:
and then in an entirely different script to generate the C
Re: (Score:2)
We seem to have gone different ways. I get how the article part is done. I'm talking about when I click the little circle next to your name, and I get three options, one for friend, one for neutral, and one for foe. If I understood your original suggestion (which I probably didn't, seeing as how we've gotten this far) I thought that you intended that the usernames on the individual friend list would be part of the css file.
First, create a CSS file for each user like this:
For instance drachenstern.css I would want to have something like (based on m
Re: (Score:2)
and this whole time, I'm talking about the script to move a.Abcd1234 (or whoever, ignore the name part) from the /* Friends */ to the /* Foes */ section
Well, we're on the same page up to that point. The difference is that in my plan, the CSS file would be the output of a program. It would never be edited in any way, just overwritten with new data whenever necessary.
I totally get that a css version would be much more server-inexpensive than heavy db lookup and code generation on the fly. In fact, the cacheability of the css on the users computer could reduce some server load that much more, no?
That's exactly correct. Basically, the CSS would be fetched from the client's browser cache most of the time.
The only part I don't immediately see being faster is code for generating friend of friend, but that could be stored on the server and updated "every-so-often", or can eat into those reduced server processing cycles
But the problem is that right now "friend of friend" is generated for you every single time you load a story. It doesn't matter if that information is identical to when you la
Re: (Score:2)
and this whole time, I'm talking about the script to move a.Abcd1234 (or whoever, ignore the name part) from the /* Friends */ to the /* Foes */ section
Well, we're on the same page up to that point. The difference is that in my plan, the CSS file would be the output of a program. It would never be edited in any way, just overwritten with new data whenever necessary.
And now the breakdown appears. Okay, clarified!
I just figure a script would be even better than generating it on the fly, but since you would only generate when you saved the configuration, it could actually lead to a better page, in a way, or at least a different version of the page with columns, or something.
see, now I feel a marginal bit better that I helped contribute to a potential resource saving upgrade for slash, by helping to make sure certain ideas were fleshed out, even though I realize that
Re: (Score:2)
I am notoriously bad at following through on these things. :-D
Re: (Score:2)
My family has gone to the trouble of finding a shirt that says:
I think this is a pretty bad idea. (Score:2)
Re: (Score:2)
Good point, although I would still think the relationship information so relatively unimportant compared to other content that it wouldn't be missed. However, now that you bring it up, the same approach would work almost as well if it generated DOM-modifying JavaScript so that the client applied the relationship information instead of the server. Would that work OK with screen readers and such?