User Tools

Site Tools


designers:philosophy

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
designers:philosophy [2013/10/28 22:47]
jonyo [RWD in Layman's Terms]
designers:philosophy [2014/09/25 16:55] (current)
Line 19: Line 19:
   * Keep your site up to date with every release. When allowing multiple versions to pass between updates, the more versions are released, the more changes you will have to make at once.  It's generally much easier to apply smaller changes more often than, say, trying to apply changes added over an entire year, from 2-3 new feature releases or more, all at once. <   * Keep your site up to date with every release. When allowing multiple versions to pass between updates, the more versions are released, the more changes you will have to make at once.  It's generally much easier to apply smaller changes more often than, say, trying to apply changes added over an entire year, from 2-3 new feature releases or more, all at once. <
   * Apply changes to a test site first. That way, you can make any required design changes on the test site so that your "live" site experiences very little down time. <   * Apply changes to a test site first. That way, you can make any required design changes on the test site so that your "live" site experiences very little down time. <
 +  * Note that this isn't something you will be needing every other update.  Historically, if you look at the changelogs and release notes, we tend to make "major" design changes about once every 2 years or so.  The recent 7.1 re-design then 7.3 re-design is the exception to this, as 7.1 was done for "cosmetic" reasons (to give the software a "face lift"), while the re-design in 7.3 was done in order to change to use RWD, to make the software design more mobile friendly.  We will try to keep the previous trend in place, a design update hopefully no more than once every other year. <
  
 ===== Responsive Web Design VS Separate Mobile Design ===== ===== Responsive Web Design VS Separate Mobile Design =====
Line 43: Line 44:
  
 Now enters Responsive Web Design (RWD).  RWD is the **next logical step** for CSS: before you could easily change the entire design by "swapping out" CSS files.  Now we have something called "media queries", which allow specifying CSS that is used only when the screen size is a certain size.  So now instead of swapping out a CSS file, you have different CSS defined in the same CSS file, but entire sections of the CSS are only used based on the screen size.  This allows us to do the "totally different design" based entirely on what the screen size is, rather than swapping out the CSS file.  That's all there is to RWD, it's just a fancy way to make CSS apply only for certain screen sizes((Actually there is a lot more that media queries can do, but the screen size is how it is used for RWD.)), so that we can change the design and layout to respond to the size of the screen. Now enters Responsive Web Design (RWD).  RWD is the **next logical step** for CSS: before you could easily change the entire design by "swapping out" CSS files.  Now we have something called "media queries", which allow specifying CSS that is used only when the screen size is a certain size.  So now instead of swapping out a CSS file, you have different CSS defined in the same CSS file, but entire sections of the CSS are only used based on the screen size.  This allows us to do the "totally different design" based entirely on what the screen size is, rather than swapping out the CSS file.  That's all there is to RWD, it's just a fancy way to make CSS apply only for certain screen sizes((Actually there is a lot more that media queries can do, but the screen size is how it is used for RWD.)), so that we can change the design and layout to respond to the size of the screen.
- 
-We've seen some blog posts / critics (not specifically about the software, but regarding RWD in general), that insist that you cannot have the same HTML page used for mobile or for a screen as large as a wall, that doing so somehow results in sub-par design for both sizes.  To those I would ask, why not?  If your content uses good semantic HTML, why can't you make an awesome design for small screens, and make the layout adjust to the larger screens?  There are many examples across the web that prove that idea wrong.  Just because there are a few examples of RWD done the "wrong way" does not mean you cannot do it right.  Now we won't say it is easy, it is quite a challenge to make the same HTML markup completely warp and change according to the screen size if you want to "start from scratch" rather than starting from the RWD framework built into the software.  If it were easy, everyone would be doing it.  But don't totally dismiss it as impossible either! 
- 
-Ultimately the software gives you the choice to go the route you would like, we just want to make sure you are making a fully informed decision!  Choose a mobile-only template set perhaps because you want to limit what the mobile device shows((something we don't agree with, but hey this is your site :) )), or because it might be cheaper to create a mobile template instead of creating a unified RWD based design... 
 ===== RWD Principals We Follow ===== ===== RWD Principals We Follow =====
  
-First, note that these are principals we follow for the default design, and things we highly recommend you do for your own website, but ultimately you do have full control over the design of your site so you can do anything you want on your own site.  :-)+First, note that these are principals we follow for the default design, and tend to be considered "best practice" in the industry in a lot of cases, but ultimately you do have full control over the design of your site so you can do anything you want on your own site.  :-)
 ==== Do Not Restrict Functionality ==== ==== Do Not Restrict Functionality ====
  
Line 67: Line 64:
  
 And most importantly, removing them did not remove any functionality from the mobile view, as mentioned the images are only cosmetic.  It speed up the page load time since the mobile did not have to download those images, and in our opinion in the mobile view it looks better without fading images in the background.  Had that not been the case, if those fading images were not merely cosmetic, we would have found a way to still show them on the mobile view. And most importantly, removing them did not remove any functionality from the mobile view, as mentioned the images are only cosmetic.  It speed up the page load time since the mobile did not have to download those images, and in our opinion in the mobile view it looks better without fading images in the background.  Had that not been the case, if those fading images were not merely cosmetic, we would have found a way to still show them on the mobile view.
 +
 +==== Semantic Standards Compliant HTML ====
 +
 +All HTML in the default design, is fully W3C compliant HTML 5.  We also make the HTML as "semantic" as possible.
 +
 +We avoid solutions that require complicated HTML markup that does not make much sense when you look at it.
 +
 +When it comes to images serving as links, we avoid making those images a background image defined in CSS, instead having the image tag directly in the HTML.  There are times when this may still make more sense for optimization reasons, but is avoided for the most part.  Doing so misses out on an opportunity to use the alt attribute to let search engines know what the image is for (and humans as well).
 +
 +=== Exceptions that Prove the Rule ===
 +
 +If you plug the demo into the W3C validator at http://validator.w3.org/ - you will see 1 error, caused by this line:
 +
 +<code html><meta http-equiv="X-UA-Compatible" content="IE=edge"></code>
 +
 +This is the one exception, technically it is not valid HTML 5.  However, the line is needed to make sure Internet Explorer versions 8 through 10 display the page as best as they can.  You can see more information about it at [[startup_tutorial_and_checklist:design_configuration:specific_html_elements:overall_layout#X-UA-Compatible Meta Tag]].
 +==== Less (HTML) is More ====
 +
 +This one goes hand in hand with [[#Semantic Standards Compliant HTML]] - we try to use as "little" HTML markup as possible, while still having semantic markup.  It accomplishes 3 things:
 +
 +  * Easier for **humans** to read and understand the HTML markup.
 +  * In theory, should be easier for browsers to interpret the markup, and therefor speed the page up.
 +  * Less HTML means smaller download, and faster loading page.
 +
 +This means we avoid complicated HTML markup.  If we can find a way to accomplish something in a semantic way, while reducing the HTML, we will do so.  One good example of this is the new ((As of version 7.3)) way that we use to mark up navigation links.
 +
 +This is one common way to represent navigation links in HTML 5, we do NOT do it this way anymore as of version 7.3:
 +<code><!-- OLD way -->
 +<nav>
 + <ul>
 + <li><a href="#">Link 1</a></li>
 + <li><a href="#">Link 2</a></li>
 + </ul>
 +</nav></code>
 +
 +Note that this is simplified to just the "markup only", CSS classes and such are stripped out.
 +
 +That way is indeed very semantic, first you know these are navigation links because of the <nav> tag.  And you know it is a list of things by the <ul> and <li> tags.  But it does use a lot of HTML.  We took that, and basically removed the list tags, since when you look at it, with the <nav> tags alone, it should already be pretty obvious that it is a list of navigation links.  We felt that also including the list tags were a little redundant, and un-needed since the HTML 5 <nav> tag already acts to "encapsulate" the list of navigation links.
 +
 +The reduced version that we use in the default design uses this format:
 +<code html><nav>
 + <a href="#">Link 1</a>
 + <a href="#">Link 2</a>
 +</nav></code>
 ===== Progressive Enhancement ===== ===== Progressive Enhancement =====
  
designers/philosophy.1383000467.txt.gz · Last modified: 2014/09/25 16:55 (external edit)