This article is the first of a four part series:
- Epic AdventureWorks Part 1 - The Blueprints
- Epic AdventureWorks Part 2 - The Model
- Epic AdventureWorks Part 3 - The Web App
- Epic AdventureWorks Part 4 - The Style
Check out the AdventureWorks ASP.NET Sample ASP.NET app online.
We wanted to build a real-world ASP.NET sample app as a resource to our dev community, here are the plans we came up with to do just that!
I wanted to use AdventureWorks since there is a blatant lack of (complete) samples for this great sample database for SQL Server. The next blog in the series will cover more detail on the database. This article is going to walk you through our (crazy) process of building a real ASP.NET application from the gorund up.
What better place to start than on paper? In my opinion there is no substitution for sitting down with the team to sketch out ideas on paper. Something creative triggers in my mind as soon as I get a Sharpie marker in my hands. The point of putting it on paper is to get everyone involved and visualize the end result. Trying to do the same thing with software or words is an immediate limitation on creativity and workflow. Below is the scanned sketches from our first brainstorming on the project. As you can see, it doesn't matter if you are an artist. Just putting pen to paper will help you construct anything. It's also important to note that these sketches are not meant to be blueprints, just ideas. So, don't try to make them perfect. We had about ten times this number of sketches that were thrown out, but they all led to this solid concept.
Check out the scanned sketches from our brainstorming session: AdventureWorksBrainstorm.pdf
From Sketch to SketchFlow
Now that we have a (very) rough idea of the web app on paper, its time to solidify it in a blueprint. To do this, I used SketchFlow since it still gives me the ability to be creative and sketch ideas together. SKetchFlow is primarily promoted as a Silverlight wireframe design tool, but I think it is perfect for wireframing any kind of software. SketchFlow has almost all of the UI elements I need to compile the mockup. When it doesn't have a UI element that I need, I can make my own with XAML or import screenshots from somewhere else.
Once I compile all of the mockups together as screens I can use the most powerful feature in SketchFlow, Export! The fact that I can export my project into a Word document makes using SketchFlow my favorite Wireframe tool. That's right, just one click and SketchFlow makes a well formatted Word document complete with screenshots and outline. Once it is in Word, I add content and notes to make a finalized blueprint. I was able to go from paper to final blueprint in one day using SketchFlow. Seriously, why not use SketchFlow for wireframing all of your projects?
Check out the blueprint draft here: AdventureWorksWeb.pdf
This screen demonstrates the navigation menu which will be at the top of every page. The home page will have some static marketing content that the design team can create. It will merely link to a few sections of the site. The menu is constructed of base categories and the submenu is constructed of sub-categories corresponding to their parent category.
Note: I used a screenshot from a Microsoft Sample of AdventureWorksLT as a placeholder for home page content. The important part of this screen was to show the navigation.
The categories screen demonstrates the page shown when the top level navigation menu items are clicked. The data all have sub-categories so this view lists those along with a select few products within them. The charts will be hardcoded based on the category.
This screen demonstrates the products listing which is viewed when clicking a sub-category in the previous screen (or in the second level menu). The page lists all products in a certain sub-category in a gallery view. The sidebar check for all available filters for this list and gives controls for the end user to filter with.
This screen also demonstrates the Netflix-style tooltip that pops up over each product in the list. It displays the name, price, and some stats from the product.
The bike screen demonstrates the product details view. This is the screen shown when a product link is clicked. It shows the model description of the product, name, price, specs, related products, and recently viewed products. The screen has a "Buy Now" link for people to purchase the product online. The chart will be hardcoded based on the category.
This screen is what is shown when the user clicks "Buy Now". They get a popup screen that informs them of an item being added to the cart. It also shows the current items in their cart and links to continue shopping or checkout.
This screen demonstrates the website authentication. It forces the user to login or signup to checkout. The username and password should be hardcoded and prefilled for demo purposes.
The shopping cart is the first step of four in the checkout process. This screen allows the user to edit their shopping cart items, quantity, and shipping. It also shows their progress in the checkout process.
This is the second step of four in the checkout process. It pre-fills the users information based on their profile (hardcoded for demo purposes). The user can also edit any part of this form to see the interaction with our input controls.
The shipping screen allows the user to select their preferred shipping date. It also allows them to optionally change shipping information.
Review order screen is to allow the user to double-check their order before it gets processed. They can click "back" to change any part of the order before clicking "complete order".
Receipt confirms or denies their transaction, for demo purposes we will set it to always confirm. This screen serves as a receipt/invoice for them to print or email.