Apr 24, 2009 at 2:11 PM
OK, from our last thread, here's a complete list of everything people came up with for possible applications to build.
* Pinewood Derby Tracker
* Real Estate Listing System
* Personal Media Library
* Time and Expense Tracking
* Code Snippet Library
* Desktop Client for MSDN Forums
* Instant Messaging Client
* Personal Accounting Software
* RSS Reader
* Stock Market/Portfolio Management
* Fantasy Sports Team Manager
* CRM/Call Center
* Employee Database
* Payroll System
* Inventory Control System
* Purchasing System
* Trouble Ticket System
* Recipe Database
* Password Keeper
* Photo Album
* Genealogy Program
* Scrum Tool
It's not too late to add to this list, but it's time to start discussing our options. At this point, I don't think +1 type votes are helpful yet. The list is too large, for one thing. For another, there's no indication of "why" when we vote +1.
No, what I'd like to see first is a discussion about why you like or dislike options in the list. Try to persuade folks why they should vote +1 for your favorites, and why they shouldn't vote +1 for ones you don't like. Try to tie the reasoning back to our
goals and requirements.
Let the discussions begin.
As a reference application, the feature set is less important than the pattern that we are demonstrating. We should therefore choose the smallest feature set that can benefit from the pattern.
A line-of-business application, while more representative of our audience's actual needs, tends to have a large set of requirements. These requirements tend to be tightly focused on a specialized business domain. It will therefore likely be unfamiliar to developers
not working in that business domain.
A personal application, on the other hand, tends to be familiar to a broader slice of our target audience. It may not represent the line-of-business application that they are tasked with creating, but at least they will understand its requirements well enough
to see past them.
I therefore would favor the smaller personal applications, such as the recipe database or the pinewood derby tracker, over the larger and more focused line-of-business applications, such as the stock market/portfolio manager or the CRM/call center.
Apr 24, 2009 at 8:48 PM
Solid reasoning, for the most part. However, I'm not sure that a Recipe DB is all that small. Features mentioned in the previous thread, such as social aspects, meal planning, nutrition tracking and even just quantity scaling, can make such an application
quite large. Yes, we can scale the features back to keep the sample small, but the same could be done with any of the applications in the list above. For an example, just see the RI included in Prism.
I will agree totally, though, that the best way to be understandable to the largest possible audience is to stick with a personal application. Pet Shop did this (everyone uses a shopping cart application, even if they've never coded one). Some applications
that I'd personally rule out (this does NOT mean they are ruled out) based on this include: CRM/Call Center, Purchasing System, Trouble Ticket System and Scrum Tool. These are niche enough to exclude some folks from being able to understand the domain, and
thus would hinder what the focus is on here.
I just listened to Chuck Hienzelman on The Thirsty Developer talking about building a recipe app using SQL Server 2008 (http://thirstydeveloper.com/default,date,2009-04-27.aspx).
It is tempting to use his feature set to define our reference application. It would give us an out-of-the-box non-MVVM (presumably) reference implementation. But, since Chuck is not a part of this project, he is not beholden to the rules of the other RIs.
That said, I still favor the recipe database for its multiple interacting views. For example:
While we want an application with multiple views of the same data, we also want rich interaction on each of those views to highlight the messaging. Apps like the pine car derby tracker take input from just one source, and display that data in different ways.
Those views don't interact so much as report.
- Browse recipes by tag. Open a recipe and tag it. See the browse window update.
- List recipes by available inventory. Adjust inventory and see recipe list update.
- View a running shopping list. Plan meals for the month and see shopping list grow. Add items to the shopping list and see possible recipes light up.
The RSS reader example is similarly limited in interaction. Feeds come from one direction, and all the user can do is subscribe/unsubscribe and mark as read.