7. Content Inventory
• A complete table of all the documents on a
website
Content Inventory Version Control CSS Style Guide
8. Content Inventory
• A complete table of all the documents on a
website
• Useful for identifying redundant, outdated,
or trivial content
Content Inventory Version Control CSS Style Guide
10. Build an Inventory
• Use a site map generator to create a list.
• http://code.google.com/p/sitemap-
generators/wiki/SitemapGenerators
• http://www.xml-sitemaps.com/
11. Build an Inventory
• Use a site map generator to create a list.
• http://code.google.com/p/sitemap-
generators/wiki/SitemapGenerators
• http://www.xml-sitemaps.com/
• Index all documents
12. Build an Inventory
• Use a site map generator to create a list.
• http://code.google.com/p/sitemap-
generators/wiki/SitemapGenerators
• http://www.xml-sitemaps.com/
• Index all documents
• Inspect duplicates from symlinks or
redirects
17. Get Everyone Involved
• Consider:
• Stakeholders have the organization’s
best interests in mind.
• Content owners know the subject best.
• Developers consider web standards,
usability, and search optimization.
18. Get Everyone Involved
• Consider:
• Stakeholders have the organization’s
best interests in mind.
• Content owners know the subject best.
• Developers consider web standards,
usability, and search optimization.
• The inventory serves as a tool to aid
discussion during content review.
19. Ask Questions About
Your Content.
• Does anyone read this stuff?
• What is its purpose?
• Is it written for our audience?
• Is it in the right place?
• Can I combine it with something else?
23. Delegate and Review
• Break up the work
• Identify key sections
• Seek assistance from people who are
unfamiliar with the content under review.
24. Delegate and Review
• Break up the work
• Identify key sections
• Seek assistance from people who are
unfamiliar with the content under review.
• Meet several times to compare notes and
develop your content strategy.
25. “Like the Sun, the West Bank Union rose on
the East Bank before settling in on the West
Bank. Coffman Memorial Union conducted
programming on the West Bank in the
1960s. Coffman Program Director Carl
Nelson had aspirations of creating a West
Bank Union, so in 1968 he uprooted himself
from the East Bank to become the first
director of the newly established West Bank
Union.”
“...The sun sets in the west, but the West
Bank Skyway is set to continue shining on
the West Bank.”
28. Manage Scope Creep
• Expect requests for changes during
planning and development.
29. Manage Scope Creep
• Expect requests for changes during
planning and development.
• Use your inventory as a reference for
keeping your project on schedule.
30. Manage Scope Creep
• Expect requests for changes during
planning and development.
• Use your inventory as a reference for
keeping your project on schedule.
• Consider the inventory as a project
specification.
34. Our Experience
• With large amounts of content,
details are easily overlooked.
• Designs or wireframes may be
useful to preview the results.
35. Our Experience
• With large amounts of content,
details are easily overlooked.
• Designs or wireframes may be
useful to preview the results.
• Build consensus
36. Our Experience
• With large amounts of content,
details are easily overlooked.
• Designs or wireframes may be
useful to preview the results.
• Build consensus
• Document your organization’s
decisions!
37. Now, how
about the code?
Content Inventory Version Control CSS Style Guide
76. CSS Style Guide
• Reference for developers
Content Inventory Version Control CSS Style Guide
77. CSS Style Guide
• Reference for developers
• Web page to demonstrate
classes & id’s
Content Inventory Version Control CSS Style Guide
78. CSS Style Guide
• Reference for developers
• Web page to demonstrate
classes & id’s
• Not necessarily a framework
Content Inventory Version Control CSS Style Guide
79. CSS Style Guide
• Reference for developers
• Web page to demonstrate
classes & id’s
• Not necessarily a framework
• Not a coding spec
Content Inventory Version Control CSS Style Guide
80.
81.
82. “Even Hipsters need a refresher course from
time to time, and you wouldn't want to be
throwing out dated slang like ‘grody’ or ‘wicked’
when mixing with other Hipsters in the know.”
89. Why not use a CSS
framework?
ez-css (ez-css.org)
90. Why not use a CSS
framework?
ez-css (ez-css.org)
I was the only one working on the project
91. Why not use a CSS
framework?
ez-css (ez-css.org)
I was the only one working on the project
Flexible (literally & figuratively)
92. Why not use a CSS
framework?
ez-css (ez-css.org)
I was the only one working on the project
Flexible (literally & figuratively)
Light footprint
93. Why not use a CSS
framework?
ez-css (ez-css.org)
I was the only one working on the project
Flexible (literally & figuratively)
Light footprint
Layout & design decisions were still in flux
94.
95. “I find the ez-css classes to be remarkably
un-semantic...”
123. Website Redesign
Project
• Major restructuring of content
Content Inventory Version Control CSS Style Guide
124. Website Redesign
Project
• Major restructuring of content
• Easy deployment of new code libraries
Content Inventory Version Control CSS Style Guide
125. Website Redesign
Project
• Major restructuring of content
• Easy deployment of new code libraries
• Painless page builds
Content Inventory Version Control CSS Style Guide
126.
127. Project Tools in Web
Development
What are your questions?
sua.umn.edu/minnewebcon
Ken Loomis - @kmloomis
Ethan Poole - @ethanp
Tony Thomas - @truetone
Notes de l'éditeur
-Welcome\n-Focus of presentation\n-Audience\n-Three goals in redesign\n
-Content became less structured over time; four domains\n-Relied on content inventory to keep track of changes and requests\n-Will talk about content inventory and how it benefited dept. for communication and project tool\n
-Content became less structured over time; four domains\n-Relied on content inventory to keep track of changes and requests\n-Will talk about content inventory and how it benefited dept. for communication and project tool\n
-Content became less structured over time; four domains\n-Relied on content inventory to keep track of changes and requests\n-Will talk about content inventory and how it benefited dept. for communication and project tool\n
-Huge subject\n-Small web team, big website. No dedicated content specialist.\n-Questions to audience\n-Quickly define and give overview of how a content inventory is built\n
-Huge subject\n-Small web team, big website. No dedicated content specialist.\n-Questions to audience\n-Quickly define and give overview of how a content inventory is built\n
-Could make a list yourself but it will take a long, long time\n-Sitemap generators, web spiders are better. Integrity for Mac also works well.\n
-Could make a list yourself but it will take a long, long time\n-Sitemap generators, web spiders are better. Integrity for Mac also works well.\n
-Could make a list yourself but it will take a long, long time\n-Sitemap generators, web spiders are better. Integrity for Mac also works well.\n
-Any spreadsheet application will work\n-Google Docs is good for those of us at the University b/c it’s available to all\n
-Add identifiers first: link, content name\n
-No right or wrong way to do this\n-Spreadsheet should be mostly empty at this point.\n-Your instinct will be to dive right in, fill it in (and get it over with), but don’t (yet).\n
-Many different groups should be involved and have a stake in the final result\n-Explain group perspectives\n-The content inventory is your centerpiece in the discussion. It’s objective.\n
-Many different groups should be involved and have a stake in the final result\n-Explain group perspectives\n-The content inventory is your centerpiece in the discussion. It’s objective.\n
-You might have technical and non-technical staff working together on the inventory.\n-Use Analytics.\n
-Be reasonable. Not all sections may need review.\n-At SUA, we didn’t use Google Docs right up front. Consolidated results of individual reviews.\n-Filling in the inventory is tedious. Occasionally you’ll find some evidence that work will pay off.\n
-Be reasonable. Not all sections may need review.\n-At SUA, we didn’t use Google Docs right up front. Consolidated results of individual reviews.\n-Filling in the inventory is tedious. Occasionally you’ll find some evidence that work will pay off.\n
-Be reasonable. Not all sections may need review.\n-At SUA, we didn’t use Google Docs right up front. Consolidated results of individual reviews.\n-Filling in the inventory is tedious. Occasionally you’ll find some evidence that work will pay off.\n
-Be reasonable. Not all sections may need review.\n-At SUA, we didn’t use Google Docs right up front. Consolidated results of individual reviews.\n-Filling in the inventory is tedious. Occasionally you’ll find some evidence that work will pay off.\n
-This was there for a long time, and I’m not sure why.\n
-Preview of the final inventory\n-Used color coding for completed, pending tasks\n-Helpful features\n
-Someone will have a new idea; sometimes it’s a good one\n-Might be okay to adjust, but make sure you are involving all of your original participants\n-Sometimes you have to reject requests that are out of scope; use CI as specification\n
-Someone will have a new idea; sometimes it’s a good one\n-Might be okay to adjust, but make sure you are involving all of your original participants\n-Sometimes you have to reject requests that are out of scope; use CI as specification\n
-Someone will have a new idea; sometimes it’s a good one\n-Might be okay to adjust, but make sure you are involving all of your original participants\n-Sometimes you have to reject requests that are out of scope; use CI as specification\n
\n
-Be thorough; plan ahead as much as possible\n-SUA DIDN’T use wireframes, but probably would have been helpful\n-Documentation: CI is the final result, but does not show the reasons for doing things a certain way.\n
-Be thorough; plan ahead as much as possible\n-SUA DIDN’T use wireframes, but probably would have been helpful\n-Documentation: CI is the final result, but does not show the reasons for doing things a certain way.\n
-Be thorough; plan ahead as much as possible\n-SUA DIDN’T use wireframes, but probably would have been helpful\n-Documentation: CI is the final result, but does not show the reasons for doing things a certain way.\n
-Be thorough; plan ahead as much as possible\n-SUA DIDN’T use wireframes, but probably would have been helpful\n-Documentation: CI is the final result, but does not show the reasons for doing things a certain way.\n
\n
To get the status of a file, you might think to use "cvs status", but that returns this cryptic text that is utterly useless.\n
To get the status of a file, you might think to use "cvs status", but that returns this cryptic text that is utterly useless.\n
Instead, you use "cvs -nq update" to get the status of a file or of all your files.  These cryptic types of commands made CVS difficult to use.\n\nI have seen series of bash scripts that provide a sensible set of CVS commands.  However, why can't the commands just be intuitive from the start?\n
We were mainly using CVS to manage the code between the development website and the live website.  A fairly simple set up.  There were a few repositories with checkouts for each developer, but this was a fairly new addition to our workflow.\n
- Code was often overwritten or broken between commits and updates.  CVS didn't have the tools for effectively merging changes.\n\n- Commits were mammoth in that they contained far too many code changes.  In order to avoid constantly breaking everyone else's code, we didn't commit very often.  A commit might contain a whole day's worth of work.  This made managing changes and rollbacks a headache.\n\n- And, as mentioned earlier, the commands were nearly impossible to remember.\n
- Code was often overwritten or broken between commits and updates.  CVS didn't have the tools for effectively merging changes.\n\n- Commits were mammoth in that they contained far too many code changes.  In order to avoid constantly breaking everyone else's code, we didn't commit very often.  A commit might contain a whole day's worth of work.  This made managing changes and rollbacks a headache.\n\n- And, as mentioned earlier, the commands were nearly impossible to remember.\n
- Code was often overwritten or broken between commits and updates.  CVS didn't have the tools for effectively merging changes.\n\n- Commits were mammoth in that they contained far too many code changes.  In order to avoid constantly breaking everyone else's code, we didn't commit very often.  A commit might contain a whole day's worth of work.  This made managing changes and rollbacks a headache.\n\n- And, as mentioned earlier, the commands were nearly impossible to remember.\n
We had heard a lot about distributed version-control systems, like Git and Mercurial, and we really liked the flexibility and robustness that this model provided. Essentially, each checkout is a repository in and of itself. A “Central Repository” is only a connivence. You can commit locally and then push your changes to another repository, which allows you to commit without worrying about breaking everyone else’s code. \n
- Committing more often means that code changes are more granular.  You can look at a commit log and see exactly how the code progressed.\n\n- The distributed model provides a development team with more flexibility than the traditional model.\n\nEx:\nBobby can commit every minute code change, whilst Susy can submit commit only when she feels ready for deployment\n\nEx:\nMary can develop every piece of new functionality in cloned copies of her personal repositories, whilst Bill can develop everything in his own single repository\n
- Committing more often means that code changes are more granular.  You can look at a commit log and see exactly how the code progressed.\n\n- The distributed model provides a development team with more flexibility than the traditional model.\n\nEx:\nBobby can commit every minute code change, whilst Susy can submit commit only when she feels ready for deployment\n\nEx:\nMary can develop every piece of new functionality in cloned copies of her personal repositories, whilst Bill can develop everything in his own single repository\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Once we had decided that a distributed model was more advantageous, we had to decide between the two major players: Mercurial and Git.  This required a lot of reading and research, especially considering that each community is rather vocal about why the other community is wrong.\n\nHowever, for us, Mercurial was more attractive than Git for a few reasons:\n\n- Mercurial's command set is much more akin to SVN.  Git's commands are easy to use, but Mercurial had a few extras that are particularly useful, such as "hg addremove".\n\n- Git comprises 144 binaries, whilst Mercurial only one.  Some argue that Git's separate single-task binaries make it easier to build your "own workflow" or VC application on top of it.  That's great, but we just want to do VC plain and simple.\n\n- Git is notorious for having problems on Windows and other non-*nix systems.  Mercurial is written in Python, with a few C libraries, and is consequently more cross platform.\n\n- A lot of people do not like Mercurial's varied methods to perform branching.  This really depends on developer preference, but we liked the clone-to-branch practice of Mercurial.  It's simple an doesn't require any complex branch switching or revision history management that one might find in Git.\n\n- Last, Mercurial has a dedicated infrastructure for extensions.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
Mercurial is used by a lot of cool people: Python, Mozilla, etc. As an aside, Perl uses Git, so if you love Perl, you’ll love Git.\n
\n
Both Mercurial and Git either come bundled or have available numerous tools to migrate from SVN, CVS, etc. Mercurial can even convert from Git! Don't be afraid to switch because the migration tools work well!\n
I will give a few examples, but also talk about how the team used it\nreference for developers\nweb page to demonstrate how styles look\nnot necessarily a framework\nnot a coding spec\n
I will give a few examples, but also talk about how the team used it\nreference for developers\nweb page to demonstrate how styles look\nnot necessarily a framework\nnot a coding spec\n
I will give a few examples, but also talk about how the team used it\nreference for developers\nweb page to demonstrate how styles look\nnot necessarily a framework\nnot a coding spec\n
I will give a few examples, but also talk about how the team used it\nreference for developers\nweb page to demonstrate how styles look\nnot necessarily a framework\nnot a coding spec\n
not a new idea\nwe had an existing style guide\n some styles out of date\n wanted to update common styles for the new design\n
We wanted this.\nwanted to use cool, new stuff\n
even hipsters need a refresher course...\nnew names\nnew styles\n
converted CamelCase\n among other things, lowercase is consistent w/ XHTML coding spec\n
converted CamelCase\n among other things, lowercase is consistent w/ XHTML coding spec\n
converted CamelCase\n among other things, lowercase is consistent w/ XHTML coding spec\n
converted CamelCase\n among other things, lowercase is consistent w/ XHTML coding spec\n
initially I did\n
initially I did\n
initially I did\n
initially I did\n
initially I did\n
designs approved\ntime to start building out pages\nshared initial version of style guide w/ other developers\n my work came under review\n this was a moment when I was forced to reevaluate\n
ez-fl is fairly easy, so is ez-50. Anyone want to guess what ez-negmr does? Or what purpose a div w/ that class has?\n
All the CSS frameworks I’ve worked with have poor semantics\nThey all have one thing in common. (Next)\n
These sorts of classes put presentation back into our markup--which is precisely what we’ve been trying to get away from for a long time.\n
solved problems that needed solving\nkept semantics in mind\nmost frameworks focus heavily on page layout & columns -- just call them columns.\neven this is a compromise\nwe can change appearance w/o changing markup -- or use media queries\n
The widths and margins > 100%\n
So we need to take the margin off the third column.\n
Not hard to guess the purpose of an element w/ #main-content id.\nWhat if this were ‘span-6’?\n It would have no semantic value.\n
One-column layout.\n
common page elements\n one, two and three column layouts\neach page will only use 1 at most -- id’s instead of classes\ncontextual based on a content-based decision\n
one portion of the style guide itself\n demonstration of styles\n explanatory paragraph\n code snippet\n
one portion of the style guide itself\n demonstration of styles\n explanatory paragraph\n code snippet\n
one portion of the style guide itself\n demonstration of styles\n explanatory paragraph\n code snippet\n
one portion of the style guide itself\n demonstration of styles\n explanatory paragraph\n code snippet\n
one portion of the style guide itself\n demonstration of styles\n explanatory paragraph\n code snippet\n
site contained many two-column tables\nconverted to definition lists\n25 lines are reduced to...\n
15 lines.\nname-value pairs better semantically as a DL\n
Looks like this\n
list benefits\nchance to review markup for the entire site\nguiding document that led to consensus\ndiscussions - semantics, accessibility, naming conventions, evaluate how presentation problems are solved\nbuilds consensus\n
list benefits\nchance to review markup for the entire site\nguiding document that led to consensus\ndiscussions - semantics, accessibility, naming conventions, evaluate how presentation problems are solved\nbuilds consensus\n
list benefits\nchance to review markup for the entire site\nguiding document that led to consensus\ndiscussions - semantics, accessibility, naming conventions, evaluate how presentation problems are solved\nbuilds consensus\n
list benefits\nchance to review markup for the entire site\nguiding document that led to consensus\ndiscussions - semantics, accessibility, naming conventions, evaluate how presentation problems are solved\nbuilds consensus\n
list benefits\nchance to review markup for the entire site\nguiding document that led to consensus\ndiscussions - semantics, accessibility, naming conventions, evaluate how presentation problems are solved\nbuilds consensus\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
Combined several domains & restructured content based on consensus with Marketing; Better content strategy\nPage builds went fast; Good communication amongst developers\nEasy application and code library deployment at launch time\n
