Tag: software

Mobile Camp Brussels 2010

The insights and considerations MobileCamp Brussels #mcbxl triggered on options, technologies and tools for developing applications for mobile devices.

Some weeks ago I heard some echos over the twitter channel about #mcbxl. On Saturday, May 8th, 2010, the first edition of MobileCamp Brussels would be organized by some guys that I was following. I decided to register so as to check out the state of art of mobile computing, mobile internet and the real-time web in general.

Barcamp

This event would also be my first barcamp,  so I was pretty excited about that too. A barcamp is a free, user-generated unconference by means of  open, particapatory workshop-events, whose content is provided by the participants themselves. So, you can summarize this event as an unplanned geek gathering. Hey, if you know most participants only by their Twitter names … But what an experience that barcamp was! I love the small scale. I adore the interactivity. Energizing! A big thanks goes to the sponsors for the first class venue, catering, etc; to the organizers @emich, @steffest, @kodel and @janosizoltan for … well, organizing this event; and to all the speakers for sharing their experience and knowledge.

State of the mobile development art

Now off to mobile apps. Well, this subtitle says it all. That’s what I seem to have learned at #mcbxl. Development for mobile platforms still seems more of an art than craftsmenship. Yes, for mobile apps you have a totally different target audience and medium, so, yes, you should therefore completely realign your apps. This is what @kodel also explains in his presentation on Mobile Interaction Models. But, as proven by @Steffest‘s geek’o’tar and his presentation on cross-device development, while a fantastic exploit, it makes one wonder whether the mobile devices are becoming to mobile development what the browsers are to web development: a testing nightmare. The mobile devices apparently have even more variability in features than browsers have bugs. @gregone shares his experiences during his talk on Designing for Touch Screens.

Largest common denominator for mobile applications?

The cases presented at #mcbxl, have fairly specific requirements. Indeed, not everyone wants to write his own keyboard application, isn’t it? However, MobileCamp Brussels wasn’t too clear about what features cross-platform development tools like Titanium offer and up to what point  mobile web applications can take us. @kodel explicitly mentions to stick with native apps for now, forcing you to choose your deployment platform. Hence, he rightfully says to very carefully choose, depending on your audience!

Or limitless possibilities of the mobile devices?

The reason to go native? Remember that a good mobile app takes the user’s context into account for the services offered. Therefore access to the full features of the mobile device are most likely a key requirement. Hence, the need (for now) to choose for native applications … to fully exploit all possibilities of those devices, only limited by our own creativity.

TIY = Try It Yourself

As with everything in technology, you can only thoroughly make up you mind, after you Tried It Yourself. Mobile web, cross-platform or native, MobileCamp Brussels certainly stung my desire 😉 to experiment myself. I’ll be rigging my mobile development environment pretty soon.

So please check back once and a while if you are interested to read about my findings. On the other hand, If you yourself have some ideas or experiences to share, please do not hesitate to leave a comment!

Scrum Guide

The Scrum Guide by Ken Schwaber on ScrumAlliance is a condense (14 pages) and recent (May 2009) pocket guide on the major principles and guidelines of Scrum. It’s also gives very practical advice and tips on concrete issues when implementing Scrum.

Just thought I’d share … Yesterday, I came across a nice piece of reading material for everyone interested in Scrum as agile methodology. The Scrum Guide by Ken Schwaber on ScrumAlliance is a condense (14 pages) and recent (May 2009) pocket guide on the major principles and guidelines of Scrum. It’s also gives very practical advice and tips on concrete issues when implementing Scrum.

I think this is an excellent reference manual for anyone interested in a good overview on Scrum. Even a document  to keep at hand when working with Scrum on a project.

Design Driven Development

Design Driven development (D3) starts from the premise that the design of any system is an accident that kicks in at conception. Hence, maximizing the opportunities to make that accidents happen is the key for (product) innovation. Thereto D3 integrates design games into the project iteration at the start of the sprints, where the design games can provide input to the product backlogs. However, no process can guarantee a better design; creating the right environment with the right set of people is the only way to bring innovation and design. The Design Cube defines the people, culture and environment aspects that contribute to an innovative organization.

Anybody that is working on software engineering, software development and/or agile methodologies, will be very interested in the ideas from the Design Driven Development (D3) website.

Premise

The premise they start with is that the design of any system is an accident that kicks in at conception. Hence, maximizing the opportunities to make that accidents happen is the key for (product) innovation.

Agility

Thereto, the author(s) define procedures and practices on how to integrate design in your iterative product life cycle. D3 makes the clear distinction between the management, engineering and design aspects of product development. Most current agile practices focus on the former aspects, whereas D3 introduces the latter by integrating design games into the project iteration, nl. at the start of the sprints, where the design games can provide input to the product backlogs.

Design Games

D3 turns the design practices into set of games, which brings different sets of people, skills and experiences together to make design decisions in a collaborative way. D3 describes 11 different design games, which are grouped into five different categories: Startup, Understand, Question, Design and Experience.

But first and foremost, D3 is about focusing on the solution and not the problem. D3  can be as simple as the hilarious example laid out in their blog.

I4

D3 defines 4 fundamental elements of good design:

  • Innovation is larger level breakthrough in solving the indented problem
  • Interaction is about how software or products behave with the users
  • Information is how you arrange the different elements on the screen
  • Intelligence focus on little things which can change the usability of an application.

In this way, D3 tries to bring design to the higher level of the solution space, whereas design used to remain at the product’s code and/or architecture level. The solution is the boundary where the product ends and thus where you as a solution builder can have impact. The higher levels of business and life on the other hand need to be impacted by other means.

Design Cube

D3 also recognizes that no process can guarantee a better design. Creating the right environment with the right set of people is the only way to bring innovation and design. Guidelines to this are laid out in the Design Cube, which defines the people, culture and environment aspects which can greatly contribute to build an innovative organization.

Conclusion

The ideas laid out in the D3 approach seem to be very viable. However, they have to be tested into practice to prove if they do bring enough value to the solution development in the form of product innovation. Most certainly, more practical guidelines, best practices, procedures and tools will have to be defined.

I do have some projects on my radar that might be helped by incorporating the ideas of D3. But in the mean time, does anyone have any practical experience with the D3 or other principles on entailing product innovation in solution development?