Check out our new Front Page

Science Blogs Dot Com has revised the way its own Front Page looks. Here. Please have a look and tell us what you think!

Comments

  1. #1 pete
    January 27, 2009

    I think the new layout bites. With the old layout I could open different blogs in new tabs. Not any more. I wish they would go back.

  2. #2 Virgil Samms
    January 27, 2009

    I think it sucks. Next question.

  3. #3 CyberLizard
    January 27, 2009

    Since I usually use Google Reader to check the blogs, I have no clue what the difference is with the front page. But after taking a look, I’d have to agree with the first commenter. When the list of blogs were links, you could open them in tabs, but that option is eliminated with the dropdown automatically opening the blog. The new functionality is great if you’re drilling directly to one blog, but it is too restrictive with regards to different users browsing habits. I would recommend that the dropdown stay and that the links be added back.

  4. #4 Stephanie Z
    January 27, 2009

    I tend to use the 24-hour page when I’m browsing instead of the front page, but I’m not a big fan of the changes either. The content to space ratio is smaller, which requires more navigation, the point about tabbed browsing is an excellent one, and I thought the old page used background color better to set off the different sections of the page. This page just requires more attention and work.

  5. #5 Andrew
    January 27, 2009

    There seems to be no support anywhere on any page for mobiles.

  6. #6 Ben Breuer
    January 27, 2009

    I’m not a fan either, especially of the drop down menu to get to the blogs. I liked the directed click version better. Then again, perhaps I need to change my habits …

  7. #7 Rocky
    January 27, 2009

    Didn’t know the drop-down was there. Still sucks. Have to go to one of the topic pages to find the list again (for the same reason others have noted – tabbed browsing. I hate it and won’t use it. Have to change my start point if they keep it.

  8. #8 Stacy
    January 27, 2009

    Well … I like it!! Was there always a “New York Times” widget? If there was – I never noticed it before.

    I also like having a broader view of the top posts.

  9. #9 Dan J
    January 27, 2009

    Well, not bad as far as basic visual layout goes, but there are some issues.

    The page can’t be validated because the stated character set (utf-8) is not used for the encoding of the “Most German” links. (Someone has some work to do on displaying that text.) If you increase the text size (in Firefox, at least), the layout is completely screwed (entire right column drops below the main content – this doesn’t happen on the individual blog pages). Serious styling issue (CSS) with the subscription box at the top right. That section also has a level 6 heading (H6) which is very inappropriate for the document structure. Some other heading levels are skipped throughout the document. I think someone chose them based on the “look” rather than a semantic context.

    Somebody there at SB needs my help. *grin*

  10. #10 Strider
    January 27, 2009

    Sucks.

  11. #11 gruebait
    January 27, 2009

    I like it just for the links to blog categories along the top of the page – for one thing, it means less editing to do when I periodically scrape the blogroll in the left-hand column for my local homepage – and that ‘channel’ page reads like http://news.google's text mode, so it’s a pleasure in lynx.

  12. #12 Lurkbot
    January 27, 2009

    I never go to the front page, anyway, so I suppose this is irrelevant, BUT, if the same web designer has a crack at the rest of SB’s pages, I’ll point this out: I have several things superimposed on other things, which is a sure sign the new page is not 100% compatible with Safari. I haven’t tried Firefox yet, since it takes extreme provocation to get me to fire up that PoS.

  13. #13 Dan J
    January 27, 2009

    Well, I think it’s less the “designer” than the person implementing that design with the XHTML and CSS. They’re having to pull information from myriad sources and include files, and they’re not all done as thoroughly as hoped. There is a problem with text (that’s supposed to be inside a link) overflowing onto the right column from the link to Blog Around the Clock. The button for the newsletter form at the top is half-hidden, dropping below the bottom of its container, and it’s also flush left in that container, unlike the rest of the content. The “Rightful Place Project” isn’t quite positioned as the rest of the right-column content: needs a little more margin on the left.

    This is in Firefox 3.0.5 in Linux (64-bit).

  14. #14 chezjake
    January 27, 2009

    @ Lurkbot
    I never go to the front page, anyway, so I suppose this is irrelevant…

    [best Cockney] Hit’s not irrelevant, hit’s a bleedin’ ‘ippopotamus. [/best Cockney]

    Foolishness aside, I too seldom visit the front page. And I see some superimposition in Firefox (on a Mac) too. Also, too much scrolling and the loss of the right column to the bottom of the page if you increase font size.

    Like Stephanie, I use the 24 hour page and open posts in new tabs, so using the front page is out at least until they return the full blog list in the sidebar.

    Bottom line – unsatisfactory for my use.

  15. #15 Dan J
    January 27, 2009

    Something that I frequently do, that I’m sure most people don’t, is to look at the HTML source of web pages. I’ve never really done that with Scienceblogs.com before today. What I see is not pretty. The home page itself is bad enough, and the blogs themselves have more problems.

    Yes, it works (to a certain extent), but it’s definitely not up to standards. The pages are full of errors and non-semantic markup. The content-type meta tag is needlessly duplicated in the individual blog pages. Using tags like and for bold and italic is no longer seen as a good way to do things. Those tags imply the “look” of the text, not the “meaning”. It’s preferable to use and to imply “emphasized” and “strong” text, which can be displayed in any manner suggested by the CSS (defaulting to italic and bold, respectively). The accessibility of the pages isn’t good at all. Without javascript, many functions of the site simply disappear, rather than having a viable alternative presented.

    The inline CSS here on Greg’s pages (borrowed from PZ) should really be moved to an external style sheet. It’s eating up bandwidth that isn’t necessary. (Personally, I prefer the styling used in that CSS compared to Scienceblogs.com’s default styling.)

    I could go on, but it’s late and I’m off to bed. Let’s just say that as I see it, the Scienceblogs.com XHTML has a very long way to go.

  16. #16 Greg Laden
    January 28, 2009

    Although I personally use (out of haibit) ‘em’ and ‘strong’, I don’t understand why ‘i’ and ‘b’ are wrong. If a writer wants it bold, it should be bold, and any post hoc rethinking by CSS sheet is not good.

    Especailly in science, where, for instance, species names are supposed to be italicized, not ‘emphasized’.

    Anyway, those are all interesting comment. I’ve also noticed the malformedness of the code on this site. I have not looked lately, but paragraph and list tags are not balanced or proper XHTML, for instance (last time I looked).

    SB uses moveable type which, in turn, is written in perl. Just in case you were interested.

  17. #17 Dan J
    January 28, 2009

    Although I personally use (out of habit) ‘em’ and ‘strong’, I don’t understand why ‘i’ and ‘b’ are wrong. If a writer wants it bold, it should be bold, and any post hoc rethinking by CSS sheet is not good.

    Especially in science, where, for instance, species names are supposed to be italicized, not ‘emphasized’.

    The use of the ‘b’ and ‘i’ tags is not wrong, per se, but let’s say that it doesn’t conform to one of the primary goals of XHTML, which is the separation of content and presentation. The XHTML markup should signify the type and structure of the document’s content, while the presentation of that content is the sole responsibility of the CSS (though the browsers have default presentation attributes for each type of content).

    For content such as the species name, take the following example:

    Australopithecus anamensis, Australopithecus afarensis and Australopithecus africanus are among the most famous of the extinct hominids.

    The species names should be italicized, per common convention. How best to do this? You could surround each name with an ‘i’ tag, rendering the italics suitably. What does this suggest to a machine parsing the document? Nothing. You could use the ‘em’ tag, which by default will render italicized, but (as you suggested) you aren’t really emphasizing the names, just setting them apart, as their content is distinct.

    My preferred method would be like this:

    ‘span class=”species”‘Australopithecus anamensis’/span’, ‘span class=”species”‘Australopithecus afarensis’/span’ and ‘span class=”species”‘Australopithecus africanus’/span’ are among the most famous of the extinct hominids.

    And in the CSS:

    span.species {font-style:italic;}

    This would indicate that the text within that span has a special class, ‘species’, and the CSS indicates that it should be rendered as italicized.

    Does this make more sense? I suppose to most people it really doesn’t make any difference, as they see the same thing on their web page. To a machine parsing that text, be it a screen-reader or a search engine spider, the text takes on special meaning because of its content and context, not because of its presentation.

  18. #18 Greg Laden
    January 28, 2009

    Yes, I had thought of that. A species class that is actually pert of XHTML may even be a good idea, because it is widely required and there are a lot of reasons one might want to identify species binomials in XHTML and other kinds of documents. For instance, one could generate a convention in a particular document that the first appearance at a certain text level (chapter) is fully written out and subsequent instances use the abbreviated form.

    However, this leads us to two other problems that is ignored by the XHTML and CSS based standards:

    1) If all contributors of text have to understand XHTML standards, then writing on the web becomes a restricted and/or elitist activity; and (not unrelated)

    2) People writing comments in or blog posts who do not control CSS are forced to either not have access to certain conventions at all or to cheat with incorrect, non standard, or depricated code.

  19. #19 Dan J
    January 28, 2009

    However, this leads us to two other problems that is ignored by the XHTML and CSS based standards:

    1) If all contributors of text have to understand XHTML standards, then writing on the web becomes a restricted and/or elitist activity; and (not unrelated)

    2) People writing comments in or blog posts who do not control CSS are forced to either not have access to certain conventions at all or to cheat with incorrect, non standard, or depricated code.

    This is (in my opinion) the really big barrier to self-publishing on the web for the masses. Most blog software includes an editor such as TinyMCE for WYSIWYG page generation. Unfortunately, these editors are rather generic. They allow the person editing the post to select various types of content, but often don’t present this content in the way intended, or using XHTML that does not conform to standards. This is a problem endemic to many web page editors, though many improvements have been made in the past couple years.

    The ability to specify classes for specific tags is often included in the editors, but what about the associated styling? The author of a science article should not have to be an expert in XHTML/CSS in addition to their primary area of study.

    For a site such as Science Blogs, there are many instances of specific classes of information that are routinely used within the blog posts. Perhaps each of these types should be identified, and a consensus reached as to how each should be presented. Then these classes would be specified in the CSS, and a “cheat sheet” presented to the blog authors to let them know which classes are available for their use. Better yet, the WYSIWYG editor could be customized to allow these types of items to be selected at the click of a button. How about a “scientific edition” of the editor in use?