Differences

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

--- designers:philosophy [2013/10/24 19:10]
jonyo [RWD Principals We Follow]
+++ 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. <
   * 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 =====
@@ Line 38: / Line 39: @@
 Rather than try to "force" devices into one of two or three different categories, the default design uses RWD((As of version 7.3.0)), which allows for responding to each specific device's capabilities and screen size.  For example: we might build capabilities for touch devices so things work with a "swipe", to best take advantage of that capability on touch-capable devices, while also building in UI improvements specifically for use on devices with a pointer (mouse) and its ability to trigger "hover" events -- an interface that makes full use of the capabilities of the viewing device. Meanwhile, both options would be built "on top" of a rock-solid basic user interface that does not rely specifically on one capability or the other.  In other words, start from a basic foundation and "build up" to enhance the experience based on what the device is capable of without being "reliant" on any one capability.  See [[#Progressive Enhancement]] below for more information.
-===== RWD Principals We Follow =====
+===== RWD in Layman's Terms =====
-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.  :-)
+Way back, more than a decade ago now, when CSS 1 was first coming out and started to get used, the big "advantage" was the complete separation of style and "markup".  At the "purest form", you would create your HTML markup semantically.  For instance, use <h1> tag for something that is a heading level 1, NOT for the purpose of style, but because you want to say "this is a heading level 1".  Or you would use <p> tag for a paragraph, etc.  Then you use CSS to style those tags, perhaps give all headings a fancy shadow, and perhaps make the entire page use one font, and headings use another.  One of the big "demonstrations" of the day, was to show the exact same page, using different CSS files to completely and utterly change the entire look of the entire page.  At the HTML level, the HTML was exactly the same, the entire design of the page changed simply by using a different CSS file to style the HTML.  And this was back in **CSS 1** days, using a single HTML markup and using CSS to change the look **is nothing new**.
+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.
+===== RWD Principals We Follow =====
+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 ====
@@ Line 48: / Line 53: @@
 That is why we do not believe in limiting, "dumbing down", or otherwise restricting access to things on a website just because you happen to be visiting on one device or another.  We think everyone should be able to do anything they can do on a desktop, they should also be able to do on a mobile phone.  You will not find anything in the default design that limits access to mobile or desktop views.
-**Exceptions that prove the rule:**
+=== Exceptions that prove the rule ===
 There are a few exceptions in the default design, at least they may appear to be exceptions at first glance.  Below we'll mention the different parts:
@@ Line 54: / Line 59: @@
 **Sections //hidden// in smaller view:**  On the home page, you may notice it does not show the full top menu when you first view the site.  It also does not show the full list of categories, and a few other sections are hidden when you first view the site.  These are actually not entirely hidden, they are just "tucked away" so that you tap on the section title to display the section.  This is done for one main reason: on smaller screens, we want to show the "important part" of the page first, and get rid of any "clutter" that visitors typically don't need.  But rather than getting rid of or hiding it entirely, it is actually just "collapsed", for instance on the home page to see the list of categories, you would just tap on the **All Categories** title.
-**Fading Graphics in Search Box Hidden:**  On the desktop view, you will see images that fade in and out on the right hand side of the fancy search box on the home page.  Those images were entirely hidden from the mobile view((And by the way, they were done in such a way so that most mobile browsers will not un-necessarily download the extra graphics when they are not displayed, so it speeds the page up.)), as a **design decision**, as those graphics are 100% "cosmetic" to the site.  They serve to functional use.  They are not images of actual items on the site, they are just basically background images to make the search box look neat in the desktop view and draw your attention to the search.
+**Fading Graphics in Search Box Hidden:**  On the desktop view, you will see images that fade in and out on the right hand side of the fancy search box on the home page.  Those images were entirely hidden from the mobile view((And by the way, they were done in such a way so that most mobile browsers will not un-necessarily download the extra graphics when they are not displayed, so it speeds the page up.)), as a **design decision**, as those graphics are 100% "cosmetic" to the site.  They serve no functional use.  They are not images of actual items on the site, they are just basically background images to make the search box look neat in the desktop view and draw your attention to the search.
 Having the images display in the mobile view tends to be very "choppy" on most mobile devices.  Even on the high end devices that the fade is smooth, in our opinion it looked out of place on a small mobile screen.  They are meant partly to draw your attention to the search feature, but on mobile devices, that is basically the main thing on the page before you scroll, there is no need to draw the user's eye to that part of the page.
 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 =====
-The "old way" that developers have used for years was something called **graceful degradation**.  What that means is that if some fancy bell or whistle does not work on a device, it has "workarounds" built in so that the basic functionality still "works".  For instance, a fancy slider that might not work on an old version of IE might just display the contents in rows instead of using a slider to slide between them.  This development / design approach "starts with" all the bells and whistles, then "degrades" into "sort of working" on older technology.  And because it starts with all the bells and whistles, it tends to be bells and whistles based around a very specific set of capabilities, usually for desktops.
+The "old way" that developers have used for years was something called **graceful degradation**.  What that means is that if some fancy bell or whistle does not work on a device, it has "workarounds" built in so that the basic functionality still "works".  For instance, a fancy slider that might not work on an old version of IE might just display the contents in rows instead of using a slider to slide between them.  This development / design approach "starts with" all the bells and whistles, then "degrades" into "sort of working" on older technology.  And because it starts with all the bells and whistles, it tends to be bells and whistles based around a very specific set of capabilities, usually for desktops.  This is a good practice to follow, especially compared to no "fall back" solutions at all, but it does have it's limitations.
 The new kid on the block, so to speak, is **Progressive Enhancement**.  The new kid looks at the "old ways" and asks the room in general, "But why?" It flips the old methodology on its head by starting from the basic experience and focusing on that for the main part of the design, then later adding bells and whistles based on what is available! It starts by using a solid base to lay the foundation, then adds up on top of that based on what the device can handle.

Geodesic Solutions Community Wiki

User Tools

Site Tools

Differences

Page Tools