Geodesic Solutions Community Wiki

User Tools

Site Tools

You are here: Auction and Classified Software Support Home » Designers » Philosophy
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/24 19:15]
jonyo [Do Not Restrict Functionality] 		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 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. 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 ==== ==== Do Not Restrict Functionality ====
  
Line 59: 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.1382642128.txt.gz · Last modified: 2014/09/25 16:55 (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki