Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Migration from 800 width to 1024

Expand Messages
  • James Page
    Nick, ... I wasn t been clear. What I was trying to say is that it is important to design for a minimum and maximum screen dimensions, not aim for a fixed
    Message 1 of 8 , Aug 31 10:24 AM
    • 0 Attachment
      Nick,
       
      If you have an application page where the relative positioning of
      items is important, then this won't work.

      I wasn't been clear. What I was trying to say is that it is important to design for a minimum and maximum screen dimensions, not aim for a fixed dimension. If the relative positioning of an item is important then you alter the amount of white space. But most sites contain less important information, that can be moved down, or up on smaller screens.

      For example (and no way a real suggestion) on your "Buy Travel" page on BA. The "Change your search" could be moved to the top or bottom of page for people with smaller screens, but left where it is for people with wider dimensions.

      Some rows of information can be placed on two lines. For example using the example above "Dates" and "Airports" could span two lines for people who's browsers are width challenged.
       
      If you look at your logs, no browser dimensions make up more than about 40% of total users. Also your logs are telling you screen resolution, and not the dimensions that the user has the browser at.  Many people with large screens will not have their browser maximised. And SymbianOS/Ipod/Iphone do not report resolutions at all.

      What I'm not sure about is where the Agile approach would be
      different to waterfall in such a case, apart maybe from the analysis?

      If you where test the HTML on real peoples  (not live on the site, but within a test enviroment) screens, and screen enlargers, you would gain feedback faster if the design worked or not.

      James

      On Sun, Aug 31, 2008 at 5:27 PM, Nick Gassman <nick@...> wrote:

      On Sat, 30 Aug 2008 16:38:42 +0100, James wrote:

      >It does depend on the application, and the target audience, but my advice to design for a minimum width and a
      maximum width. HTML with layers is designed to float, so that if the
      width constrains an element it drops to the next row. So you do not
      have to design for a target screen size, just a minimum and maximum.
      >
      If you have an application page where the relative positioning of
      items is important, then this won't work. I also don't think it would
      work to have some fluid pages, and some constrained, so the end result
      for me is that it's not a good idea.

      >
      >The best way to see what works is to move as fast as possible to HTML.

      Well I think this relates to the debate on prototyping (of any sort),
      and I don't think this statement holds true as a generalisation. In
      this case, I don't want to impact the broader business by doing some
      experiments on the live site - I don't want to take that risk.

      I also don't yet know enough about the costs of designing and building
      wider pages in html, compared with the cost of designing and building
      low-fi prototypes on which we could get some valid feedback.

      It may be that we do some research and decide that the best thing to
      do would be to e.g. build out the headers and footers to the wider
      width, and put these all live in one go, and then incrementally build
      out the content. In such a case, we'd have to build all of the headers
      and footers (which may be simple, or it may not be), and couldn't just
      do some. What I'm not sure about is where the Agile approach would be
      different to waterfall in such a case, apart maybe from the analysis?


      * Nick Gassman - Usability and Standards Manager - http://ba.com *

    Your message has been successfully submitted and would be delivered to recipients shortly.