What should we build?

Apr 20, 2009 at 9:28 PM
OK, the discussion on requirements has wound down to the point of being a dead discussion for a couple of days.  Sorry I didn't post this new discussion sooner, but my eldest son's birthday was this weekend, and Dad was just too busy.

Anyway, here's a summary of the previous discussion and what our requirements/goals are.

Why ViewModel?
    * Seperation of concerns: the VM separates the logic driving the UI from the presentation itself. This allows the logic to change with minimal impact on the presentation.
    * Testability: the VM can be verified using standard unit testing instead of requiring an automation framework as would be necessary with a standard code-behind.
    * Enhancing the Developer-Designer Workflow ("Blendability"): the VM allows the developer to expose intent to the designer giving them free reign to interpret how best to visualize that intent.
   
   
 Goals
    * The BRI (Base Reference Implementation) must be compatible with WPF and SL, and we may want to include a BRI for each platform.
        * There is NOT a requirement that any RI provide implementations for both.
    * The BRI should be something "real", with features that a developer might actually have to implement in their day jobs.
    * The BRI should include common scenarios that a developer would face in many applications.
        * Navigation (opening/closing windows and/or "page" navigation)
        * Communication between "views"
        * Event handling
        * Commanding
        * MessageBox
        * Focus control
        * Selection (particularly multiple) tracking
        * Asynchronous (remote?) operations
        * Validation (both immediate (local) and delayed (remote))
        * Exception handling
        * Common dialog usage
    * The BRI shall include:
        * A full business/domain layer, including unit tests, that handles all business/domain logic and persistence. Should we include "design time data" in any fashion?
        * An application layer, coded in "tradition spaghetti codebehind" fashion. This gives RIs a starting point, including assets such as images and styles. This does NOT include any tests.
        * Extensive documentation (including Guidance?)
    * The BRI should have a professional designer's touch.

I left out a requirement that it be LOB related. We need to cover LOB scenarios, but I don't want to limit our choices to business type applications.  A password keeper has many of the same requirements as a LOB application, for instance.

I think this covers everything.  If I got something wrong or missed something, please respond.

So, given this set of goals/requirements, let's start discussing possibilities for our BRI.  I'll open it up with something creative, just to get people's juices flowing. There was a sample application I had intended to build for Onyx anyway, that I think can meet all of our requirements nicely.  I don't expect this will be the application we decide to build, but since it would work and is creative, I thought it would be a great place to start out. The application is a Boy/Cub Scout Derby Race tracker.  There's not many of these out there, and they are a great use to Scouts, which is good for the community.  For those not familiar, the Scout derby race is a race in which scouts build pinewood car models and race them on a slotted track.  Tracking software is used to track information about contestents, calculate who races whom in each heat, track winners of heats and eventually of the entire race, etc.  About the only thing not necessitated by the application without some thought is asynchronous/remote operations, but I'm sure we could think of something here.  Maybe tweet race results?

OK, I started things.  Let's here what you think about the Derby software, or any other ideas you have for our BRI.

Apr 20, 2009 at 9:36 PM
I think this all sounds good.  I'm in favor of the Pinewood Derby idea, it sounds like fun.  Thanks for kicking off this thread, Bill.

Josh
Apr 20, 2009 at 10:24 PM

I'll throw out a few ideas (with those I really like in bold)

  • Real Estate Listing System (not necessarily full MLS)
  • Personal Media Library (track books, movies, games, etc., possibly tracking loans out and in)
  • Time and expense tracking (there's a nice set of specifications on the web that we can refine/develop against)
  • Code snippet library (organize and share sample code)
  • Desktop client for MSDN Forums (there have been five projects started and stopped for this)
  • Instant Messaging Client
  • Personal accounting software
  • RSS Reader
  • Stock Market/Portfolio Management
  • Fantasy Sports Team Manager

There are others floating around in here but my leading ladies are calling :)

Apr 20, 2009 at 11:33 PM
Nice list Mike.  The ones I particularly like:

Media library - Like the derby, I'm not sure what async operations we'd have here.  This is also light on business logic.  However, this is an application everyone can imagine coding and using.

Personal accounting software - Again, I'm not sure where the async hooks are here.  This certainly has some business log, though.  It also may prove to be much more complicated than our BRI should be if we're not careful about feature creep.

IM client - This one could be a tad light in functionality, and isn't LOB oriented, though some radical thinking could beef this up with some unique features.

RSS reader - In many ways, this one would be ideal, and is one I thought about as well.  The main problem here is that it's not very LOB like.  It's also been done to death :)

Stock market/portfolio management - Has a feeling of "been there, done that", but fits all of our criteria better than other suggestions.
Apr 21, 2009 at 2:10 AM
I'd like to propose CRM/Call Center, or some variation on that theme.
  • It's a real LOB app.
  • You can view the sales process from different perspectives, giving us communication between the views.
  • There are plenty of opportunities for navigation, selection, focus, and context.
  • Business rules must be exposed through the view model, and therefore unit tested at that level.
  • Screens like on-call timer with customer info will benefit from a designer's skill.
  • Asynchronous communication with a (mock) PBX.
Apr 21, 2009 at 2:49 AM
I like that one! +1 to Call Center app.
Apr 21, 2009 at 7:04 PM
A call center app certainly does fit the goals perfectly.  Personally, I don't find it exciting, though.  Partially because as LOB applications go, call center apps are the most boring.  Partially because, the one time I worked on one of these, I'd rather just forget that experience. ;)

Of course, I'm not going to vote against it, and if others think this is the best idea, I'll go along for the ride. :)  So instead of +1, I'm neutral.
Apr 21, 2009 at 10:10 PM
Time Tracker +1
Apr 22, 2009 at 1:33 PM
CRM/Call Center +1
Apr 22, 2009 at 1:52 PM

Call Center sound alright, so +1

Apr 22, 2009 at 1:54 PM

Call Center sound alright, so +1

Apr 22, 2009 at 1:59 PM

Call Center sound alright, so +1

Apr 22, 2009 at 2:05 PM
Some other LOB ideas, maybe more common than a call center app:

Employee Database
Payroll System
Inventory Control System
Purchasing System
Trouble Ticket System

Some other more personal program ideas:

Recipe Database
Password Keeper
Photo Album
Genealogy Program
Apr 22, 2009 at 2:28 PM
Was that a +3 from Orktane? :)

My wife wants a recipe database, so that gets a +1 from me.

I also have to give a +1 to the media library. I haven't used a bar-code scanner API, but I imagine that it would be asynchronous. That might be a good addition to the feature set (mocked, of course).
Apr 22, 2009 at 2:43 PM
Recipe database sounds great...could even make a meal/shopping list planner out of it. Add some social elements to it...and it's a wrap ;)
Apr 22, 2009 at 2:55 PM
From a fun application perspective, the Recipe DB is great.  I've always wanted to build one that worked with a web site/service for social elements (recipe sharing, commenting and Stack Overflow style rankings for both users and recipes).  I don't think we can get that fancy with this.  Maybe just a (simulated) online sync and publish would be enough.  Nearly every other requirement is satisfied here, though we might have to get creative for the "communication between views".  What's required here has a lot of parallels with LOB applications (form entry, reporting, table displays, searching, filtering, etc.), while at the same time retaining some appeal for non-LOB developers.
Apr 22, 2009 at 9:13 PM
I've been planning to do a recipe/meal planner app so I'll vote for that.
Apr 23, 2009 at 2:41 AM

I like the recipe idea. But I'll suggest one idea that done right, I would definitely use for my team.

- Scrum tool [scrum or a tool for any kind of agile projects]

We can be very creative here, and implement pieces that can be useful for our purpose, and pieces that we'd just like to add.
Some areas that we might include (to start picturing the idea):

  • Manage backlog
  • Manage daily commitments
  • Manage bugs
  • Several views for displaying the same ViewModel (I like the stickies view from Conchango Scrum Tool for example)
  • Drag & Drop (i.e stickies) - which BTW I believe it is a challenge we should tackle, as it is not trivial to implement with MVVM
  • Monitor the build server, set up alerts, offer to fix a build, etc
Apr 23, 2009 at 9:02 AM

I like the Scrum tool idea, always wanted to make one but never had time.

From: juliandominguez [mailto:notifications@codeplex.com]
Sent: Thursday, April 23, 2009 3:41 AM
To: laurent@galasoft.ch
Subject: Re: What should we build? [mvvmref:53904]

From: juliandominguez

I like the recipe idea. But I'll suggest one idea that done right, I would definitely use for my team.

- Scrum tool [scrum or a tool for any kind of agile projects]

We can be very creative here, and implement pieces that can be useful for our purpose, and pieces that we'd just like to add.
Some areas that we might include (to start picturing the idea):

  • Manage backlog
  • Manage daily commitments
  • Manage bugs
  • Several views for displaying the same ViewModel (I like the stickies view from Conchango Scrum Tool for example)
  • Drag & Drop (i.e stickies) - which BTW I believe it is a challenge we should tackle, as it is not trivial to implement with MVVM
  • Monitor the build server, set up alerts, offer to fix a build, etc

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Apr 23, 2009 at 12:12 PM
 +1 for the Scrum tool.
Apr 25, 2009 at 9:28 AM
How about a personal knowledge management?

Think about Mircosoft's OneNote / Google's notebook.

May 19, 2009 at 11:21 AM

+1 Scrum Tool and +1 Recipe DB

Aug 10, 2009 at 12:47 AM

Things seem kinda quiet here.

*tumbleweed*

I just did a writeup on a blog editor sample app: MVVM and Linq to SQL the easy way. It's in the spirit of Windows Live Writer. Maybe this would be a better reference application than a recipe DB, because we can use standard blog APIs for the client/server demonstration:

  • Blogger API
  • Wordpress API
  • MetaWeblog API
  • Atom Publishing Protocol

Since anyone can set up a blog, we don't need to fake out the C/S communication. Thoughts?

Sep 21, 2009 at 5:54 AM

I like the idea of the SCRUM management tool.

Another Idea: A personal health record client based on either MS HealthVault or Google Health.