Project Tools in Web Development

1,472 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,472
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • -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
  • \n
  • \n
  • Project Tools in Web Development

    1. 1. Project Tools in Web Development A Case Study Ken Loomis, Ethan Poole, Tony Thomas Student Unions and Activities, University of Minnesota
    2. 2. Website Redesign Goals
    3. 3. Website Redesign Goals• Audit and reorganize content
    4. 4. Website Redesign Goals• Audit and reorganize content• Improve code management
    5. 5. Website Redesign Goals• Audit and reorganize content• Improve code management• Create new and consistent styles
    6. 6. Content InventoryContent Inventory Version Control CSS Style Guide
    7. 7. Content Inventory• A complete table of all the documents on a website Content Inventory Version Control CSS Style Guide
    8. 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
    9. 9. Build an Inventory
    10. 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. 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. 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
    13. 13. Make a Spreadsheet Google Docs work well!
    14. 14. Add columns
    15. 15. Choose columns that fit your project. • ID • Redundant? • Title • Outdated? • Path • Trivial? • Template • Notes • Owner • Status • Summary • etc.
    16. 16. Get Everyone Involved
    17. 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. 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. 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?
    20. 20. Delegate and Review
    21. 21. Delegate and Review• Break up the work
    22. 22. Delegate and Review• Break up the work• Identify key sections
    23. 23. Delegate and Review• Break up the work• Identify key sections• Seek assistance from people who are unfamiliar with the content under review.
    24. 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. 25. “Like the Sun, the West Bank Union rose onthe East Bank before settling in on the WestBank. Coffman Memorial Union conductedprogramming on the West Bank in the1960s. Coffman Program Director CarlNelson had aspirations of creating a WestBank Union, so in 1968 he uprooted himselffrom the East Bank to become the firstdirector of the newly established West BankUnion.”“...The sun sets in the west, but the WestBank Skyway is set to continue shining onthe West Bank.”
    26. 26. Helpful features:* File > See Revision History* Tools > Notification Rules
    27. 27. Manage Scope Creep
    28. 28. Manage Scope Creep• Expect requests for changes during planning and development.
    29. 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. 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.
    31. 31. Don’t Forget...• <meta> tags• .pdf, .doc, .xls meta data• Old images, documents, videos
    32. 32. Our Experience
    33. 33. Our Experience• With large amounts of content, details are easily overlooked.
    34. 34. Our Experience• With large amounts of content, details are easily overlooked.• Designs or wireframes may be useful to preview the results.
    35. 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. 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. 37. Now, howabout the code?Content Inventory Version Control CSS Style Guide
    38. 38. cvs status hejsan.py
    39. 39. cvs status hejsan.py==============================================File: hejsan.py Status: Locally Modified Working revision: 1.4 Mon Jun 11 02:12:28 2001 Repository revision: 1.4 /home/cvsroot/hejsan.py,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
    40. 40. cvs -nq update
    41. 41. We were using CVS, albeit minimally. Central Repository Development Live Website Website
    42. 42. CVS has problems.
    43. 43. CVS has problems.• Overwritten and broken code
    44. 44. CVS has problems.• Overwritten and broken code• Mammoth commits
    45. 45. CVS has problems.• Overwritten and broken code• Mammoth commits• Cryptic commands
    46. 46. Distributed ModelLive Website Tony Central Experimental Ethan Repository WebsiteDevelopment Ken Website
    47. 47. The distributed model increases flexibility.
    48. 48. The distributed model increases flexibility.• Granular commits
    49. 49. The distributed model increases flexibility.• Granular commits• Developer flexibility
    50. 50. Why Mercurial?
    51. 51. Why Mercurial?• Easy-to-use commands
    52. 52. Why Mercurial?• Easy-to-use commands• Cross platform
    53. 53. Why Mercurial?• Easy-to-use commands• Cross platform• Easy to install and to manage
    54. 54. Why Mercurial?• Easy-to-use commands• Cross platform• Easy to install and to manage• Clone to branch
    55. 55. Traditional branching is complex.
    56. 56. Traditional branching is complex. Revision 1
    57. 57. Traditional branching is complex. Revision 1 Revision 2a Revision 2b
    58. 58. Traditional branching is complex. Revision 1 Revision 2a Revision 3a Revision 2b
    59. 59. Traditional branching is complex. Revision 1 Revision 2a Revision 3a Revision 2b Revision 3b
    60. 60. Traditional branching is complex. Revision 1 Revision 2a Revision 3a Revision 4 Revision 2b Revision 3b
    61. 61. Traditional branching is complex. Revision 1 Revision 2a Revision 3a Revision 4 Revision 2b Revision 3b
    62. 62. Clone-to-branch is straightforward.
    63. 63. Clone-to-branch is straightforward.Revision 1
    64. 64. Clone-to-branch is straightforward.Revision 1Revision 1
    65. 65. Clone-to-branch is straightforward.Revision 1Revision 1 Revision 2 Revision 3
    66. 66. Clone-to-branch is straightforward.Revision 1 Revision 2Revision 1 Revision 2 Revision 3
    67. 67. Clone-to-branch is straightforward.Revision 1 Revision 2 Revision 4Revision 1 Revision 2 Revision 3
    68. 68. Why Mercurial?• Easy-to-use commands• Cross platform• Easy to install and to manage• Clone to branch
    69. 69. Why Mercurial?• Easy-to-use commands• Cross platform• Easy to install and to manage• Clone to branch• Extensions
    70. 70. Cool people use Mercurial.• Python• Mozilla• OpenOffice.org• Vim• CodeIgniter
    71. 71. Cool people use Mercurial.• Python• Mozilla• OpenOffice.org• Vim• CodeIgniter• Student Unions & Activities
    72. 72. What if I already use aversion-control system?
    73. 73. DON’T PANICSwitching is easy.
    74. 74. CSS Style GuideContent Inventory Version Control CSS Style Guide
    75. 75. CSS Style Guide• Reference for developersContent Inventory Version Control CSS Style Guide
    76. 76. CSS Style Guide• Reference for developers• Web page to demonstrate classes & id’sContent Inventory Version Control CSS Style Guide
    77. 77. CSS Style Guide• Reference for developers• Web page to demonstrate classes & id’s• Not necessarily a frameworkContent Inventory Version Control CSS Style Guide
    78. 78. CSS Style Guide• Reference for developers• Web page to demonstrate classes & id’s• Not necessarily a framework• Not a coding specContent Inventory Version Control CSS Style Guide
    79. 79. “Even Hipsters need a refresher course fromtime to time, and you wouldnt want to bethrowing out dated slang like ‘grody’ or ‘wicked’when mixing with other Hipsters in the know.”
    80. 80. Style Guide Changes
    81. 81. Style Guide Changes• CamelCase to hyphenated lowercase
    82. 82. Style Guide Changes• CamelCase to hyphenated lowercase• Eliminate legacy styles
    83. 83. Style Guide Changes• CamelCase to hyphenated lowercase• Eliminate legacy styles• Get rid of styles that described presentation
    84. 84. Style Guide Changes• CamelCase to hyphenated lowercase• Eliminate legacy styles• Get rid of styles that described presentation• Keep notification styles (error, success, etc.)
    85. 85. Why not use a CSS framework?
    86. 86. Why not use a CSS framework?ez-css (ez-css.org)
    87. 87. Why not use a CSS framework?ez-css (ez-css.org)I was the only one working on the project
    88. 88. Why not use a CSS framework?ez-css (ez-css.org)I was the only one working on the projectFlexible (literally & figuratively)
    89. 89. Why not use a CSS framework?ez-css (ez-css.org)I was the only one working on the projectFlexible (literally & figuratively)Light footprint
    90. 90. Why not use a CSS framework?ez-css (ez-css.org)I was the only one working on the projectFlexible (literally & figuratively)Light footprintLayout & design decisions were still in flux
    91. 91. “I find the ez-css classes to be remarkablyun-semantic...”
    92. 92. ez-css class names are esoteric.
    93. 93. ez-css class names are esoteric.<div class="ez-fl ez-negmrez-50"></div>
    94. 94. Most CSS frameworksuse un-semantic names.
    95. 95. Most CSS frameworksuse un-semantic names.•ez-50 (ez-css)•container_12 (960GS)•grid_1 (960GS)•span-4 (Blueprint)
    96. 96. They all put presentation into the markup.
    97. 97. We wrote our own styles.
    98. 98. We wrote our own styles..column { float: left; margin-right: 5%; width: 45%;}
    99. 99. We wrote our own styles..column.narrow { margin-right: 5%; width: 30%;}
    100. 100. We wrote our own styles..column.last { margin-right: 0;}
    101. 101. We wrote our own styles.#main-content
    102. 102. We wrote our own styles.#main-content.extended
    103. 103. The Guide#main-content #main-content.extended#contextual
    104. 104. We refined our markup.
    105. 105. We refined our markup. <table class="data"> <thead> <tr> <th colspan="2">Heading</th> </tr> </thead> <tbody> <tr> <td><strong>Title</strong></td> <td>Definition</td> </tr> <tr> <td><strong>Title</strong></td> <td>Definition</td> </tr> <tr> <td><strong>Title</strong></td> <td>Definition</td> </tr> <tr> <td><strong>Title</strong></td> <td>Definition</td> </tr> </tbody> </table>
    106. 106. Same info. Better markup. <dl class="data"> <dt class="heading">Heading</dt> <dd> <dl> <dt>Title</dt> <dd>Definition</dd> <dt>Title</dt> <dd>Definition</dd> <dt>Title</dt> <dd>Definition</dd> <dt>Title</dt> <dd>Definition</dd> </dl> </dd> </dl>
    107. 107. Benefits
    108. 108. BenefitsEasy
    109. 109. BenefitsEasyTraining
    110. 110. BenefitsEasyTrainingGuiding document
    111. 111. BenefitsEasyTrainingGuiding documentConsensus
    112. 112. BenefitsEasy DiscussionsTraining • semanticsGuiding document • accessibilityConsensus • naming conventions • common solutions
    113. 113. Website Redesign Project
    114. 114. Website Redesign Project• Major restructuring of content Content Inventory Version Control CSS Style Guide
    115. 115. Website Redesign Project• Major restructuring of content• Easy deployment of new code libraries Content Inventory Version Control CSS Style Guide
    116. 116. Website Redesign Project• Major restructuring of content• Easy deployment of new code libraries• Painless page builds Content Inventory Version Control CSS Style Guide
    117. 117. Project Tools in Web Development What are your questions? sua.umn.edu/minnewebcon Ken Loomis - @kmloomis Ethan Poole - @ethanp Tony Thomas - @truetone

    ×