Rapidly Evolving Design

SLHvpLogo

The problem with using a blog to track a rapidly evolving design, is that blogs don’t make for very fluid documents; the unwritten rule is that once posted, you ought not go back and substantially alter a post.

Matching Blog Posts to Discussions

I do want to use these postings to keep everyone up to date on the evolution and lessons being learned in the SLHVP project, but we also need a way to consolidate the discussion and the evolving understanding, and so each blog post will refer to a specific discussion on CodePlex where the ideas will be discussed and will evolve. I’ll then post a roll up of changes periodically, but not in response to each posting. The most recent post is being discussed here, where I have recognized that I violated my own design principles and backed away from two lines in the previous blog post. Here is what I wrote:

 

Your questions reveal that I have violated my own design principles: "Do not let the design get ahead of what you know" — The right answer is, of course, to design only for what we know we need, and keep the design open enough to extend as new needs emerge. To answer your questions specifically:

…What I meant was that we know that videos will want to signal a marker has been encountered, and I can imagine that other frame components might want to signal that something has happened that is equivalent (you’ve reached the 4th level of play in this game)… then I went off the track and speculated that this should be handled by the Frame. But that is absurd.  The Frame might be the place to handle this, but I can easily imagine that there is a base class or interface that the video and game support or that there is a separate class they both associate with, etc. etc.  So let’s just strike that statement (which I will do by editing my message and referring to this discussion.

2. [Each module will have its own xml config file] Here is where I really went over the edge. I totally retract this statement. Maybe it makes sense for each module to have its own configuration file, but we’ll only know that once we have modules and we’ve worked with a single integrated configuration file (the manifest you have working). So let’s please stay with the manifest until it is manifestly not working :-)

Please do join us in the ongoing discussion. Feel free to leave comments here about the form of the post, but substantive comments about the project will be seen by the most people, and those most involved, in the ongoing Discussions.

Thanks

 

jessesig

This work is licensed under a Creative Commons license.
Share

About Jesse Liberty

Jesse Liberty is a Master Consultant for Falafel Software, and has three decades of experience writing and delivering software projects. He is the author of 2 dozen books and multiple Pluralsight courses, and has been a Technical Evangelist for Telerik and for Microsoft, a Distinguished Software Engineer for AT&T, a VP for Information Services for Citibank and a Software Architect for PBS.
This entry was posted in HyperVideo Player, Patterns & Skills and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>