Talk:Sandstone and Tile Review

From Web Services Wiki

Jump to: navigation, search

Design

  • Perhaps make the breadcrumb links a bit smaller? The size of text and contrast of this area almost compete with the header/page title. (I think there could be some discussion about having breadcrumbs above the page title while in Stanford Modern we keep the breadcrumbs as part of the main content area under the title).
    • I see your point, Randy, and will try some variations. As with a few of your other comments here, our teams should get together to discuss the extent to which Stanford Modern (SM) design criteria/approaches should apply to the unofficial offerings; my supposition going in was that few tie-ins would be required or even desired (not wanting this to appear in any way as a variant to SM).--Dave 10:04, 18 September 2009 (PDT)
  • I think the sidebar having a transparent background makes the page look "unfinished" somewhat. Perhaps a white background would work better here?
    • I tried both and didn't much like the combination of a white-background sidebar panel when pull-quotes or margin notes/comments appeared below without same (those would be far more difficult to apply backgrounds to -- I would have to take an entirely different approach). If consensus weighs toward having an opaque background always, I can go with that, but in any event I should provide the option explicitly (and show that way on an example page).--Dave 10:17, 18 September 2009 (PDT)
  • The lamp icon in the header seems somewhat kitsch. Is the intention for this to be swapped out easily or will all uses of this template have the lamp icon?
    • :) The lamp is definitely optional (it's only in markup and I'll comment it better across all of those pages, not just the one "lamp-less" one) …feedback so far indicates that this is one of those love-it-or-hate-it things.--Dave 10:17, 18 September 2009 (PDT)
  • I think having non-indented paragraphs would bring the design closer toward Stanford Modern somewhat. I'm not a big fan of serif as main text. We might have better connection to Stanford Modern if we just have the option of sans serif. (Serif headers are very nice looking, imo)
    • Yes, I like the idea of non-indented paragraphs with leading in between for sans serif body text. I'll at least make it optional in the initial set. For now, though, I'd like to keep the serif option for those whose use might call for it (e.g., some formal academic uses?).--Dave 10:23, 18 September 2009 (PDT)
  • I can foresee users wanting to put more text (address, email, office hours) in the "affiliation" section of the header. Is the template prepared for vertical stretch like this?
    • Not sure how it behaves right now, but I'll make sure the height of that section will be adjustable. Hmmm…this may mean it will be best to just dump the lamp graphic entirely or make it available somewhere else. I'll look into it.--Dave 10:26, 18 September 2009 (PDT)
  • Perhaps increase the distance between paragraphs would improve readability somewhat. I'm not sure how often "leading_above_onehalf" class would be used? (Although I may steal this idea for some of my projects :-)
    • :) As mentioned above, I'll definitely add space between paragraphs for sans serif - and perhaps a bit for the serif versions as well.--Dave 10:31, 18 September 2009 (PDT)
  • Blockquote definitely needs more vertical padding.
    • Right. I'll take care of that.--Dave 10:31, 18 September 2009 (PDT)
  • .cite_number_innotes may be better presented with the "grey" font color rather than black
    • Perhaps so…I'll look at that.--Dave 10:31, 18 September 2009 (PDT)
  • It looks like the fixed-width is smaller than 960px? I think 960px should be a standard on pages produced by ITS or Ucomm (of course, this depends on content needs and type of website).  
    • This one deserves meeting about…for a layout designed to be only 2-column, 960px leads to a content column that doesn't meet traditional text readability standards at the small sizes we're accustomed to (imo).--Dave 10:31, 18 September 2009 (PDT)


Code

The code looks highly functional.   I think some code formatting would improve code readability a bit.  Perhaps using  [ element { attribute: X; attribute2: XXX; attribute3: XXX; } rather than:

element {

     attribute: X;

     attribute: XXX;

}

 would help with scanning through the code later much easier.  Either way, I don't think it's good practice to mix the two formatting options.  Also, we should standardized on section commenting in CSS at some point.  I tend to use the crufty but noticeable:

/********************

Comment

                                        • /

while I notice that your group uses a bit cleaner (but, in my opinion, less readable) version of /* Comment /*.   Mixing the two is not a great practice.  (Although I'm sure I mix these in my projects as well)

[Randy]

Personal tools