Building a website in 40 hours, Part 4

So far in this series, we’ve talked about the importance of planning (even for Give Camp projects), the idea of “thinking with tools” to make the design process richer, and the general importance of using source control (specifically, TFS) when working on any size team to maximize productivity. Now it’s time to get in to some coding.

Best Practices for Building Site CSS Templates

If there is one thing that every modern website needs, it’s a good CSS foundation. Cascading Style Sheets are the core layout and styling tool for standards-based web development, and when used correctly, they not only help improve performance, they also help improve accessibility and SEO.

Don’t Use Tables for Layout. Embrace the (more) semantic web.

If you’re still using tables for overall site layout, stop. This is an outdated practice, riddled with problems, and the valid excuses from a few years ago that CSS is too hard no longer hold weight. A high quality website should aim to use semantic HTML whenever possible, especially when doing general site layout.

What is “semantic” HTML? Put simply, it means you use HTML that describes the content it contains.

For example, an ordered list (ol) tag should be used for lists of items. An image tag should be used for images. A div tag should be used for “dividing” areas of the screen. A table should be used for…tabluar data. When applied properly, almost every element on a page can be rendered semantically and then styled with CSS. A menu or tabstrip, for instance, should be an order list of items (not a bunch of divs). And if you use the RadControls, you’re already there…can’t help myself.

Why does all of this matter? Isn’t it simply a “religious” debate? No. There are practical reasons to follow this guidance

Continue reading CSS Template Best Practices

1. Semantic HTML is typically more concise than HTML that is used for layout, meaning smaller, faster loading pages. Faster loading because there are fewer bytes to download and fewer HTML elements for the browser to process as it renders the page (the more important factor with modern bandwidth).
2. Since semantic HTML often “offloads” all styling and layout information to external CSS sheets, performance is further boosted by the cachability of external CSS.
3. Semantic HTML is indexed better by search engines. Since the semantic usage of HTML conveys meaning about its contents, search engines can better understand which parts of your page are less important. Content, for example, should be given greater index value over navigation. It’s not “web 3.0’s” vision of a giant semantic web, but it is a valuable step.
4. Along the same lines, semantic HTML is easier for screen readers to parse, thus making its usage more accessible.

Guidelines Are Not Commandments. Bend the rules when you need to.

Sometimes a quick table for laying-out a form is easier to use than CSS. It’s true. With today’s CSS standards, lining-up columns can be tricky. Can it be done with CSS? Absolutely. Is it still easier with a table. Generally, yes.

The goal of CSS-based web design and semantic rendering is to make those situations where HTML is used for layout the rare exception and not the rule.

Save time with CSS frameworks

Programming with JavaScript today almost always starts with a framework. Whether it’s jQuery or Microsoft Ajax, very, very few people continue to write “raw” JavaScript. Why?

1. Browser’s process JavaScript differently. Frameworks abstract those differences.
2. JavaScript doesn’t provide a lot of “high level” helpers. Frameworks do and save you time.

The same is absolutely true for CSS. Browsers are notorious for processing CSS differently, and that is how CSS has earned such a painful reputation. Fortunately, CSS is being made fun again with easy to use frameworks that abstract the browsers and make CSS layouts easy. Popular options include:

1. YUI Grids (by Yahoo!)
   My personal favorite and the CSS framework of choice for Telerik at WAM Weekend. YUI is deployed on thousands of websites, so it’s tested and reliable. It makes it super easy to design your site’s layout with CSS and then extend that layout with pre-defined CSS rules. I think of it as my “blank slate” for CSS design. As a bonus, YUI Grids has a convenient visual grids builder, a well documented cheat sheet, and CDN hosted scripts.
2. Blueprint
   Another very popular CSS framework deployed on many sites. Unlike YUI Grids, which is based on special CSS classes that help you divide DIVs in to areas, Blueprint prides a CSS “grid” of columns and rows. Positioning content is a matter of simply using the Blueprint CSS rules to position your content in the right column/row. Blueprint also includes typography and form styles, so you get a bit more than layout if you want it.
3. YAML
   If you prefer a commercial solution, YAML is one of the few CSS templates that is also available with a commercial license and support. There is a free version, but it requires the display of links to YAML in your site template. Otherwise, it’s another robust framework with a visual tool for configuring CSS layouts.

With a good framework, CSS is easy and your site template can be constructed- cross-browser ready- in minutes.

From Concept to Production Ready Template (in hours)

Whether you’re doing a 2-day Give Camp or consulting project, you don’t have hours (days?) to waste on troubleshooting cross-browser CSS. Here’s how Team Telerik managed to go from concept to functional, cross-browser CSS site template in a few hours:

1. Whiteboard – sketch ideas and start conceptualizing the site’s layout
2. Mock-up – This is a bit optional for a 40-hour Give Camp, but a must for any other project. Convert those whiteboard ideas in to a collection of mockups. This process forces you to think critically think about your site and always uncovers additional requirements. Balsamiq Mockups is currently my favorite tool for this job.
3. Create at least 2 design concepts – Pop open Photoshop or (if you have a Mac) Pixelmator and come-up with a couple distinct design ideas. Don’t stop with your first idea even if you think it’s great. The process of working through two designs ensures your final design will be stronger. If you get stuck, browse the web for inspiration. TemplateBox and TemplateMonster are good inspiration starting points.
4. Build CSS layout with framework – Here I would use YUI Grids to build my basic CSS layout. That process will spit out the starting HTML and CSS that my site will need.
5. Build your site MasterPage – Now add that HTML and CSS to your “base” MasterPage (nested MasterPages are your friend).
6. Start customizing CSS – Now that your base CSS and HTML are set and your site layout is ready to work cross browser, you can start customizing with your colors, fonts, and images. Start chopping-up your Photoshop designs to get the CSS background images you need. And don’t forget to create CSS sprites when you can for maximum optimization.
7. Perfect CSS with Firefox and Firebug – One of the best tools for rapidly testing changes to CSS is Firebug. You can quickly dial-in your CSS design to perfection. And if it looks right in Firefox, it will mostly look good in Safari, Chrome, Opera, and IE7+. That just leaves IE6 for some special testing if you have to support it (and you really shouldn’t these days).

And that’s it. While it looks like a lot of steps, the most time consuming will be all of the steps before CSS. The CSS will be fast and easy and you’ll wonder why you were ever afraid of it.

CSS and the standards-based web are not hard. Stop letting people tell you that they are. They were. But so was JavaScript before jQuery. With a good CSS framework and this simple workflow, you’ll be successful getting your site template ready- 4 hours or 40 hours.

Building a website in 40 hours, Part 3

In part 1 of this ongoing series, we looked at how you lay a solid foundation for your project with planning. In part 2, we introduced the idea of thinking with tools. That is, during the design phase, expanding your developer creativity and ability by including known features from professional .NET developer tools in your web site design.

Building Software as a Team in TFS (with Sitefinity)

There are (generally) three types of software development:

1. Individual – it’s just you and your genius code
2. Small Team – You see them. They see you.
3. Big/Multi Team – You didn’t even realize your project had code that did that

The need for source control for each of these groups is present, but the motivations are very different. Individual developers often use source control as a simple way to remember what files they’re changing between releases and to have an insurance policy against local system failures or changes that require a rollback.

As soon as you are more than one person, though, source control becomes an essential productivity booster. So essential, in fact, that even for a 2 day website project, we relied heavily on source control.

But everything wasn’t smooth sailing.

Continue reading Building Software as a Team in TFS

Use source control when you need it

Especially for a fast project with a small team, sometimes its faster to work outside of source control. What? It’s true.

Here’s the deal: when you’re rapidly prototyping and building a website, it’s usually much faster to work on your small components in an isolated, focused ASP.NET website and then add your work to TFS once you’ve got your component working on its own.

This is very true for a solution with many projects, or a solution built on Sitefinity. You often don’t need the configuration hassle or build-time of the “big project” just to work on your own sliver of functionality. And since Sitefinity is based very “cleanly” on ASP.NET, you can just use a scratch ASP.NET website and “normal” ASCX user controls to quickly build and test something like a custom module before adding it to the master project. It can save you hours.

Here’s the workflow that we used for most of our Sitefinity development:

1. Each team member had their own copy of Sitefinity and OpenAccess ORM
   (IMPORTANT: Make sure each team member has the *same version* of whatever tools you’re working with. This will save headaches later.)
2. Each team member working on custom modules simply built and tested them in their own local environment. Most team members didn’t even use Sitefinity until they had a working UserControl in a “plain” ASP.NET website. Don’t introduce complexity until you have to.
3. As custom modules were completed, they were integrated in to the “main” Sitefinity website in TFS, which was a simple process of copying ASCX files, sometimes copying some DLLs (or external libraries), and updating the web.config.
4. As major updates were ready, we would FTP all changes to the staging web server.
5. Schema changes were handled in the dev environment by the OpenAccess build step (we used forward mapping for our custom objects). To deploy them to staging, we used RedGate tools.

Be careful with Web Sites in Source Control

We had one disaster with source control that cost us a few hours during WAM weekend. Sitefinity 3.7, as you may know, uses the Visual Studio Web Site “project” type. The Web Site project is based on the file system and technically does not have a “project” file. That makes Web Sites easy to work with on their own, but they are potentially problematic when other project file-base projects are added to a solution.

It so happened that part of our team had built a couple of class libraries. Not realizing that the default items in source control for a “web site” lacked a solution file, they added the class library projects to the website. This hosed our solution file.

After a few hours of trying to clean-up the mess, we had this realization:

Source control, when used correctly, saves your team time.
Source control, when used incorrectly, can destroy your team productivity with a single check-in.

Lesson? Be careful with web sites. If you can avoid website projects, do. Web Applications are much more reliable in Visual Studio. If you can’t avoid website projects, make sure you add your other projects correctly to the solution file.

One more Sitefinity Special Consideration

If time is short, don’t add the Sitefinity folder to TFS. It has literally thousands of files. Checking those files in and then subsequently checking them out is a time consuming process. It’s actually much faster to just give each member of your team the Sitefinity folder that they can add locally for testing code from TFS.

The Sitefinity folder should be a “static” resource. You shouldn’t generally need to change the files in that folder. Upload it once to your staging site and leave it.

Eventually, you’ll want to add the Sitefinity folder to your repository so that it’s easy for new team members to check-out and work with your code, but in time strapped events like Givecamp, you may be better off following this advice.

Work Items and better teams

In 40 hours, there isn’t much time for creating work items- we relied on a big whiteboard to cover that task. In the real world, though, a big whiteboard isn’t the best way to create and track work items. TFS provides work item support, but the default Visual Studio tools for working with these items remind you that VS is a coding tool.

Enter the Telerik Work Item Manager.

Work Item Manager is a tool from Telerik that helps you be as productive with managing your work items as JustCode is at making you productive with your code. And we offer it as a free tool for everyone! If you’re working with TFS and you haven’t checked WIM out, I’d really like to know why. It’s a great way to maximize the productivity of your team…when you have more than 2 days to work on a project.

Okay. Enough boilerplate conversation. On to some of the implementation details. In the next part, I’ll talk about how CSS frameworks save you tons of time and why you should be using one. We used one. Find out which one in part 4.

Building a website in 40 hours, Part 2

In part 1, we looked at how you lay a solid foundation for building a website on a very tight timeline. Planning, no matter how long you have to work, should not be “skimped” on.

Mapping requirements to deliverables with tools in mind

Requirements communicate what your client or charity want to be able to do with their website. As a web developer, you have a few choices for how you go about turning those requirements in to a schedule of work for your team. You can:

1. Build everything by hand, delivering only exactly what is defined in the requirements
2. Use tools and services to cover requirements where they make sense

When working with users to gather requirements, especially non-technical clients or users, you often need to listen past what they’re saying and try to think about how they will interact with your features when the project is done. For example, take this simple requirement:

“We want a contact form that people can use to send us an email.”

Sounds simple enough. How would you solve this requirement?

Continue reading Mapping Requirements to Deliverables with Tools

Many developers would barely stop to think before dropping a few textboxes on a page, wiring them up to a submit button, and then sending an email with the collected info. Meets the requirement, but is it enough? Is that what the evolved professional .NET developer should be delivering today?

Thinking with Tools

When you have a professional developer toolbox, you gain an entirely fresh perspective on what can be accomplished in a project with limited time. In our example above, a toolbox lets us say during the design phase:

The users want a contact form. Easy. We can not only deliver a contact form, we can deliver a form, with validation, that can be edited at any time using a simple, visual form-editing tool, that can even be reused for any other data collection purpose on the website.

In short, tools turn “No’s” in to “Yes’s” at not extra cost to your project.

Can we edit the forms on our website? Yes. (Embedded WuFoo forms)
Can we export all of our data to Excel, Word, and PDF? Yes. (Single property in RadGrid, RadEditor)
Can we crop, resize, and rotate our images? Yes. (Built-in RadEditor Image Manager)
Can we have a attractive charts for our data? Yes. (Charts for Silverlight in ASP.NET)
Can we have localized versions of all our pages? Yes (Built-in Sitefinity feature).
Can we have unicorns fly off the screen? Yes…err…no.

When you have tools you know how to use, and you understand the capabilities of those tools, you can deliver way more than expected to your clients. And since tools, like Telerik’s Premium Collection, make it easy for you, the developer, you can spend more time polishing the custom features tools don’t cover.

Designing with Tools

Now that you’re thinking with tools, you go a step further and design with tools. Instead of  designing in loose terms, you can plug-in specific tools with known capabilities and quickly get past basic scenarios. Features previously considered “extra effort,” are now “free” because they’re automatically provided by a tool. Or, at least, free to you.

Context menus.
Filtering, sorting, paging, grouping, hierarchy.
Client-side binding for desktop-like performance.
Rating controls with client-side APIs.
Word-like editing in the browser.
Scheduler with day, week, and month views and drag/drop support.
Captcha validation for forms.

Just as the wide availability of light fixtures, doors, windows, and home automation systems frees an architect to design a more impressive house, tools for .NET developers help you build better software.

Challenge

Next time you start designing a project, try thinking with the Telerik Premium Collection. Review the online demos now, get a sense for all the features built-in, and then watch during your design phase how many places you can quickly improve or enhance a feature with built-in tool features. It will feel like cheating, but it’s not.

Tools used during WAM

To build our charity’s website, we relied heavily on tools to provide superior experiences and to maximize the amount of control we could put in non-technical users’ hands. We wanted to make it possible for non-technical users to have the power to update almost any portion of the site after the project shipped- from email templates to the site header and footer.

Tools we ended-up using:

• Sitefinity
  This was the huge platform time saver. More than half of our team had never developed with Sitefinity before the 40 hour dev sprint began. Two of our team members had only casual experience with ASP.NET. We still delivered incredible results in 2 days, as did all other teams (there were more than 10) that used Sitefinity that weekend. Right out of the box we were able to give our users control over pages, content, templates, and permissions. And with a simple Module system, we quickly added custom business process support, support for customizing email templates, and many helpful page controls for performing tasks like embedding YouTube videos on a page.
• RadControls for ASP.NET AJAX
  The RadControls actually ship with Sitefinity, so it was natural to use these to extend our website. Built-in features like exporting to Excel and RadEditor’s Word-like content editing gave us quick wins in our project.
• OpenAccess ORM
  We wanted to be as productive working with our custom data as we were with our UI, so we used OpenAccess ORM for all our custom modules. Again, half of our team was new to this tool on day one, but working productively within hours.
• WuFoo
  Cool service that let’s non-technical users build and edit forms that can be embedded in a website. We used this service to empower our users to have unlimited control over forms in the future.
• Kimbia
  Our charity wanted to accept donations, and they didn’t want to use PayPal. Kimbia is like a specialized PayPal service focused exclusively on helping sites collect donations.

Now that we’ve finalized our requirements and completed our design, with tools helping us deliver on our ambitious 2 day goals, it’s time to start coding. In the next part, we’ll talk about building websites as a team in TFS.

Building a Website in 40 hours, Part 1

Welcome to the first part of a multi-part series on Telerik Watch describing the process for building an impressive website in 2 days. In this series, I am going to share tips and tricks, along with some real world stories, for building a high-quality, usable website that supports critical business processes in less than 48 hours (if you’re working on WAM Weekend Time).

The purpose of this series is two-fold:

1. If you’re going to participate in a Givecamp, this advice should help your Givecamp team deliver incredible results in the short 2-day period you have to work
2. If you’re just interested in comparing your website building process to someone else’s, this series may highlight ideas and approaches you’ve overlooked in the past

Along the way, I’ll highlight best practices for building standards-based websites, different tools and frameworks that “Team Telerik” used at We Are Microsoft 2010 to be successful, and, of course, how the Telerik tools helped us do weeks worth of work in two days.

Let’s begin…

Continue reading Building a Website if 40 hours

Pre-planning

If you’re going to participate in a Givecamp, or meet with a client for that matter, you need to do some pre-planning. You need to do some research about the people you are about to serve and try to understand their motivations, their expectations, and- critical for web development- where they’re coming from with their existing website.

The goal of pre-planning: create a list of intelligent questions.

If you can have a focused list of questions prepared for your first meeting with your charity (or client), they will have infinitely more trust in your ability to deliver high quality results. It’s like a job interview. A good interview may get you the job, but a great interview will get you the job and a signing bonus.

Requirements

There is very little I can offer on the subject of effectively gathering requirements that has not already been archived somewhere on the web. What I can say is that even in the environment of a Givecamp (or any other time constrained project), detailed requirements gathering is critical. Make sure you spend time getting answers to your pre-planning questions and really try to understand the key goals of your client’s project. Charity or not, failure at this step makes everything that follows much harder.

How much time should you spend on requirements at a Givecamp?

This will obviously vary by team and charity, but Team Telerik did not start touching code until nearly 10:00 PM on day one. We spent a solid 4 to 5 hours meeting with our charity, discussing our objectives, and mapping out our requirements for the weekend. When all was done and said, we had a huge whiteboard that defined our key deliverables, and that served as our road map for the weekend. It also served as the informal contract between our team and our charity for what would be delivered by the end of the weekend.

From our high-level objectives, we started mapping out the specific features and actions that our website would need to support. We also started to identify the tasks that would require extra research or the features that would “Nice to Haves,” but maybe not feasible in 40 hours.

Time to start coding? Nope. Not yet.

Work Smarter, Not Harder.

Now that your requirements are clearly defined, you need to start planning for the execution. Some developers would suggest that means you’re at the point where you start writing tests or code, but if you’re a “work smarter, not harder” developer, that means you want to fully evaluate the tools, services, and frameworks that already exist and that can help you do more in less time.

A great developer does not write every line of code in an application by hand. A great developer knows how to find and use great tools, only writing code where it creates unique value for the project.

With that in mind, stay tuned for part 2: Mapping requirements to deliverables with tools in mind.