Blogs from Other Sites
I’m a big fan of the mind mapping tool Mindmup and logged in today using the Opera browser.
Here’s what I saw:
This is an excellent approach to communicating about the limitations and restrictions around testing – you wouldn’t expect any less from Gojko (one of the guys behind mindmup).
It’s a great way of setting expectations but without limiting the choices made by the end users. I can still choose to continue using Opera, or I can switch to one of the other stated browsers. I have a choice – but I also know it might not perform as the developers expected.
For many companies it’s often tricky just saying “no” to supporting the mass of different browsers now available so they try to test them all. Using web analytics and analysis it’s now possible for many web companies to work out what their customers do actually use (and how many people use it), and then test against those.
One of the things that I have observed from a number of testing conferences is that none of them have any sustained focus on hiring or getting hired *.
There have been one or two sessions about the topic of hiring but nothing sustained.
The occasional tracks that I have seen have been mostly focused around the hiring strategies of big corporates where bums on seats is sometimes more important than cultural team fit.
Most testers don’t know how to get hired – I wrote a book to help bridge that gap. Those that do know how to get hired are truly in the minority and appear, at least on the surface, to be overall better testers. Mostly this is not true – they are good, but they are often no better at testing than others, it’s just they are much better at getting hired. Getting hired is a skill.
Hiring and getting hired is a vast topic and one which is fraught with contextual challenges, but I believe that a dedicated set of talks from hiring managers from a wide variety of contexts, and maybe some sessions and tutorials on writing CVs, interviewing etc would go down well at most testing conferences. It’s great being good at testing but how do you then go on and get hired…
There are supporting topics such as social profiles, writing clear CVs, networking, self education and interpersonal communication that might also make interesting tracks. Or maybe they wouldn’t. Maybe people go to testing conferences to learn about testing and not the other stuff that comes with our working world…
What are your thoughts?
* The conferences that I have been to
I’ve often wondered why we don’t have more centralized reports about the state of testing and future trends that are somewhat less bias than some of the big vendor reports out there.
If they get enough people responding it could be quite an illuminating report which will hopefully show that the industry is moving in to new advances and changes to meet economic and business demands.
I hope it tells us that. I can keep my fingers crossed.
I’m putting my support behind this survey as I think the results will be interesting. Let’s see how it goes.
At the moment the survey is not live, but you can subscribe to the QA Intelligence blog if you want to keep updated, or if you don’t want to subscribe you could keep an eye on Twitter for updates.
I’ll be sharing the updates (@rob_lambert) and no doubt Joel (@joelmonte) will be also (Joel is the guy behind the QA Intelligence blog).
"Testing helmets the old fashion way" the tweet said.
"It'd be better if that was a brick wall" one of my team said.
"Yeah, that is what the specs asked for" I said.
And how we all laughed, for just a little too long, those sad chuckles of shared recognition.
Some people say they “don’t have enough requirements to start testing,” or that the requirements are unclear or incomplete or contradictory or out of date. First, those people usually mean requirements documents; don’t confuse that with requirements, which may be explicit or tacit. There are plenty of sources of requirements-related information, and it’s a tester’s […]
I’ve got a second blog which will be feeding out to my main Twitter account. It can be found at – http://idlethoughts.postach.io/
Ok – so why another blog?
Well this is an experiment on two fronts.
Firstly – this blog is connected to my Evernote account. It’s really cool.
Secondly – I’m writing another book and as with most book writing there is inevitably a shed load of research to be done, notes to be made and observations to be aired – this is what the blog is for.
Expect to see interesting learning items, questions about software testing (especially about test management) and things that will inform my next book.
The blog posts on it are essentially a stream of consciousness and will be shorter in form than this Social Tester main site.
Many people seem certain about what happened to cause the healthcare.gov fiasco. Stories are starting to trickle out, and eventually they’ll be an ocean of them. To anyone familiar with software development, especially in large organizations, these stories include familiar elements of character and plot. From those, it’s easy to extrapolate and fill in the […]
Our community is not best served by one single group or organization. [Opinion piece follows ]
As an individual it’s important to be skeptical when we have just one single source of learning and direction for our community. If we tie ourselves to a single source (i.e. group, organization, business, scheme) we are tying ourselves to a narrow (and potentially narrowing) point of view.
If we do narrow our focus to a single source we will hinder our knowledge growth and our learning scope. I believe there is another side effect though – the wider community will become more fragmented and distant as we become less tolerant of alternative views…(I have no evidence for this, just observations)
Groups that were once a mouthpiece and meeting ground for the unheard and diverse minorities soon narrow as they find a niche, or attract a tipping point of like minded people – this is natural which is why there is always room for new groups and communities to emerge to fill the gaps.
As groups narrow they will focus on specific areas. Some of these groups will inevitably try to make money by selling services (or information) to survive, some will just tumble along whilst others will seek external funding. Some will disappear. Some that do disappear will leave a gap to be filled, some will not be missed.
We need to be sure to keep our mind open and notice when we start to become focused too narrowly on our learning and our community involvement. It’s not heresy to switch communities or to exist across several seemingly different communities. In fact, I would positively encourage mixing views and opinions together. Our interests and persona’s are elastic, we must try not to resist this.
Look at the standardization schemes. In order to scale (i.e. to make money – assuming you believe this is the primary goal of those behind them) the content must to be filtered down, made consistent and change as infrequently as possible (what a bind it would be to re-print the marketing and other collateral every week to keep up with industry innovation).
In order to embark on such a dramatic process those behind it will seek to own the learning material contained within. They may want to protect it. They may want to ensure they are the only ones offering it. They may tell you that you cannot get this learning elsewhere. (note: some communities do this also)
They are wrong. Some, if not all, of the information is available freely (or at least cheaply) to us, on any device or platform we care to consume it from. Not only that but it may be opinionated (in a good and/or bad way), will naturally be diverse (if we look far enough for it) and is hopefully being shared by people actually doing the work. It will therefore change often. This is good.
And as it’s freely available we could, and probably should, mash it around, mix it up, fine tune it, fix it, extend it, delete it, try it, ignore it and make of it what we need it to be. This will be where the giant leaps in our thinking about testing will come from. From us; the testing community mashing together ideas to see what works, and what doesn’t.
And once we’ve made of it what we want then we could share it so that others can do the same. This will lead us to an evolution (or a revolution) in the way we approach testing.
Instead of small incremental improvements on the standards/norms we might see a major sea change and a dramatic shifting of our craft – I look forward to this day.
I believe the testing community needs more people to seek out diversity in our sources of learning and inspiration.
I also believe we could challenge anyone and anything that suggests a single source of information and direction is the right thing for us. We could seek out the free and open source learning that is available to us. We could challenge the old guard and stale approaches to learning (and teaching) of software testing.
We could create a community of interest if one does not exist. We could seek clarity as to whether someone is protecting a mass of knowledge for the right reasons (and no-one should begrudge anyone making a living from selling what they know) or whether it is to seek conformity and standards of the masses.
But most of all we should try hard not to let ourselves sink in to the sea of conformity and oblivion that is consuming so many people where we simply become a nodding and compliant member of a single source of direction for our community. I know we can do better. Our craft is evolving and we need more people to help gain momentum to nudge it to a diverse future rather than single path of conformity. We can do that.
A long time ago I coded a now defunct modelling tool to help me with my testing. Half the battle with managing and reporting testing involves deciding how you will model it for the project you work on.
The generic set of formal modelling techniques I use, I often map on to:
Lightweight Subjective Status Reporting
On a recent project we wanted a lightweight way of tracking progress/thoughts/notes over time. I really wanted a subjective 'daily' summary report which provided interested viewers insight into the testing without having to ask.
As part of my normal routine I have become used to creating a daily log and updating it throughout the day. Ofttimes creating a summary section that I can offer to anyone who asks.
How to do this using Jira?
We created a custom entity called something similar to "Status Tracking Summary".
Every day, someone on the team would create this, and title it with the date "20 November 2013".
We only really cared about the title and the description attributes on the entity.
The description took the form of a set of bullets that we maintained over the day to document the status e.g.
- waiting for db schema to configure environment- release 23.45 received - not deployed yet- ... etc.
Over the day we would maintain this, so at the end of the day it might look like
- db schema and release 23.45 deployed to environment- initial sanity testing started see Jira-2567- ... etc.
I initially thought that the title would change at the end of the day to represent a summary of the summary e.g. "Environment setup and sanity testing", "Defect retesting after new release". But this never felt natural and added no real value so the title normally reflected the date.
Typically, as a team of 3-4, we had 5 - 15 bullets on the list.
Use Dashboards to make things visible
To make it visible, we added a "Filter" on this entity, and added Filter display gadget to the testing dashboard which displayed the last 2 status updates.
This meant that anyone viewing the testing dashboard could see subjective statements of progress throughout the day, and historical end of day summaries throughout the project.
But people don't like writing reports
I have grown used to tracking my day through bullets and actions that I take it for granted that everyone can do this. Still, I had initial concerns that not everyone on the team would add to the status and I might have to chase.
Fortunately that didn't happen.
The team used the Dashboard throughout the day to see what defects they had allocated to them, and to work on tasks and defects in the appropriate state. Therefore they always saw the subjective daily status report when they visited the Dashboard and updating it became a natural task during the day.
You can report Daily, with mininal overhead
Very often stakeholders ask us to prepare daily reports. I find that creating, and updating, a summary log throughout the day often satisfies that requirement.
As a team, building it into our documentation process throughout the day added very little overhead and made a big difference to the stakeholders had to our testing.
I was chatting to someone at EuroSTAR last week and we got talking about personal productivity.
I shared with her my way of working using a concept I’ve been calling Shipping Forecasts. It’s based around the simple premise that I will be shipping something (a project). It is called a forecast because no amount of planning is a guarantee, so I am forecasting about what is involved in shipping this project.
My view is that projects are simply containers for tasks, and completing the tasks is what’s most important. But these tasks should be viewed in the context of what I’m trying to achieve – i.e. why am I doing this project?
Anything worth shipping will take a significant amount of effort and will need some form of forecasting.
This forecasting could be a quick scribble in a notebook or a full on project plan – a lot depends on your own style and own way of working. I like to visualise my work and list out what I believe needs to be done to complete the project.
By breaking a bigger project in to smaller chunks we can start to see what is truly involved. I also believe that any project that will take more than about 1 month should be broken down in to multiple projects. Each one of those projects should be shippable and feedback should be sought before moving on to the next project.
In a sense it’s the basics of iterative software development.
I thought I would share with you my Shipping Forecast idea that I use to break down my own projects in to manageable chunks.
Since I’ve started using this technique I’ve been uber productive.
There are times when I get a little lost or don’t feel like producing anything but rarely does a project sink because I didn’t understand it, or couldn’t actually complete it, or didn’t know what was involved in completing it.
A few people have been using the Shipping Forecast for some time now so they have been through a few reviews but there is always room for improvement – don’t expect the templates and the idea to be complete – I’m still hacking it.
How to use the Shipping Forecast templates
To start with you’ll need to define a project in the format of
This……(date, time period, month, year, etc)
If you cannot fill in these sentences then you need to question why you are doing the project.
The project must have a deadline otherwise it will meander on and on. Don’t fall in to the trap of relying on your own enthusiasm and energy. Most projects require hard work and tiresome commitment – a deadline will help. You don’t always have to specify an exact date, but the information you fill in should mean something to you. For example: “This Week” is fine if you know that your weeks finish on Saturday for example.
You should be able to describe what it is you are building at a high level. You must know how to recognise the end result. Is it a product? A website? A new blog post? A new t-shirt design? A new test automation tool? You must also think about how complete you need it to be. Are you shipping the finished item, or just phase/design 1 of it?
Your project should also have a reason why you are doing it. I’ve seen too many project stumble because the project owners didn’t know why they were doing it. Don’t do something because you think you should. Do something because you need to or want to. Why are you bothering to commit to this project?
There are some prompts below the description on the template to help you think about how you will measure your progress, how you will know you are done and whether you are reliant on others. Projects can fail because they rely on other people and these other people didn’t know that.
There is an action section with 20 spaces. If your project takes more than 20 tangible actions that can be marked as complete, then it may be that your project is too large or you have broken the activity down too much.
Some people use this form to work out the 20 activities they need to complete and then break those 20 items down further in another tool, like a To Do list manager. This could work really well but I’ve found that any more than 20 deliverable items to achieve Shipping is just too much. I find it’s better to have more projects and ship each one than try to do too much.
And that’s it. The Shipping Forecast – a tool for helping you work out what you need to do to ship stuff.Some examples
Here are some examples of Shipping Forecasts that I have done.Our Garden Project
Here is the PNG (image) of the Shipping Forecast for you to download. I’m working on getting a better quality one created.
The other day Michael Bolton tweeted this
"Art" is the activity of directing attention to things and providing affordances for interpretations. Which is why testing IS an art.I love this tweet not least because it itself affords so much opportunity for interpretation. I'm intrigued by its possibilities. I found myself picking at it, perhaps even factoring it. A few thoughts ...
"Art" is quoted. Are these scare quotes? Do they suggest some uncertainty, disagreement or ironic intent? Or are they merely an alternative to some stylistic markup such as bold font that you might see in a dictionary definition?
"Is" is emphasised in the second sentence. On that verb, that kind of marker might signify a refutation of some other assertion. Could that be the case here? What else might it be contributing?
Both "art" and "an art" are used. The former is frequently defined in terms of beauty whereas the latter is usually applied to a task that requires skill (e.g. Oxford Dictionaries). It's possible for one thing to be both. Is the use of both deliberate? Is it significant?
Natural languages contain much exception and idiom and do not lend themselves to rules and conventions. Which is why testing IS a language. "Affordances" is a relatively uncommon and quite technical word. Wikipedia describes an affordance as "a quality of an object, or an environment, which allows an individual to perform an action" but points out several variant usages. Might it have been chosen because it is the only word that gives the precisely nuanced meaning that was desired? Or because its rarity provides memorability to the whole? Or something else? Whatever the reason, it's a sore thumb here and potentially brings more than its core meaning.
The first sentence might be a definition of the term "art". It might be metaphorical or analogy. It might be explication. It might merely be attributing some property to the concept. Which is it? It is any? Could it be more than one?
The format of the tweet is syllogistic, probably a variant of the Fallacy of the Undistributed Middle in which there's an implicit premise, "testing is the activity of directing attention to things and providing affordances for interpretations". If you interpret the text literally, then it is subject to a potential logical fallacy and the extent to which you accept it depends on the extent to which you believe that the set of all art encompasses the set of all testing.
Even if your interpretation is not literal the implicit premise is hard to avoid.
Semantics is the study of meaning. Compositional semantics builds the meaning of the whole from the meaning of the parts. For instance, you can work upwards from the meanings of words via the grammar of each sentence to the meaning of the entire tweet. Restrictions are placed on higher-level potential interpretations by concrete interpretations of the components. But it's both a bane and a beauty of natural language that the information transmitted can be a gestalt: more than the sum of the words.
"Pragmatics" is the identification and application of context to observation. Which is why testing IS pragmatics.Pragmatics is a layer of meaning above semantics where context is added to the interpretation. With the right context, any and all aspects of meaning can be changed, however logical or illogical they may appear to be without it. Stylistic considerations and communicative intent can form part of this wider context. What kinds of contexts might wrap around this tweet? And need they be exclusive? A few more thoughts ...
Perhaps the structure of the tweet is simply a rhetorical device for attributing characteristics to testing. It doesn't do to overlook the obvious. Sometimes.
There's a tradition of discussion about whether testing is an art and/or a science, or art or science, or artistic or scientific. The tweet locates itself in that tradition by its subject matter.
But maybe it's also part of some specific chain of dialogue or discussion that we aren't seeing the rest of in the Twitter timeline. We've said the emphatic "is" could be a response to some other statement, something like this:
"Art" is an activity that is driven by aesthetics. Which is why testing is NOT an art.Perhaps it is sarcastic, trying to illustrate the way that carefully chosen wording can associate two distinct concepts to justify some position.
Michael has a self-declared Mcluhanite tendency to say things for their provocative effect, to make others think. So perhaps I've fallen into his trap and I'm self-yanking my chain here.
Perhaps it's just a throwaway tweet and doesn't bear any inspection: it's not intended to have any meaning beyond recording a thought in the moment it was originated.
Language can be a noisy channel for communication and Twitter as a medium naturally emphasises this because of its limit on length. But in other places other constraints apply - time, budget, the expected reader, the skills of the writer and so on. In those places and at those times where we need to minimise noise and maximise signal the onus is on us to do so by considering the kinds of messages we're sending or receiving: the words themselves and the context in which they're bundled.
Onions are made up of layers which can be difficult to uncover individually without skill and effort (and they can make you cry). Which is why testing IS an onion.P.S. Michael was kind enough to criticise an early draft of this post and my motivation for writing it. Somewhat ironically, but entirely correctly, he identified that both could be clearer.
Next week over 250 verification engineers will gather to discuss their verification challenges and discuss potential solutions (with another 80 online).
Verification is now the biggest task in any new semiconductor development. Engineers and manager face a range of challenges ranging from integrating data from a range of tools, through measuring test bench quality, how to find bugs earlier and improving vertical reuse, to resourcing projects. We will also look at the different challenges posed in FPGA verification. Plus the 50 challenges posed at previous conferences. You must be facing at least one of those challenges so why not come along and see if you can find a solution?
Registration is easy and free, and includes lunch, refreshments, conference bag and proceedings. We are in Munich, Reading and Sophia, with remote access too of course.
Why not register now or forward this to a colleague?
Too often testing is focused on getting the right answers, rather than asking worthwhile questions and helping to get them answered. There are at least two overarching questions that a tester must ask. While looking directly at the product, at its customers, at the project, at the business, and at the relationships between them, the […]
One of my major bug bears is the reliance on colour to communicate meaning. As a tester it’s super easy to question any product or communication that relies on colour. Just ask whether meaning will be lost if viewed without colour.
If you have a graph for example where each line is representing a finding or value, and they are each different colours then print the graph in greyscale and see if you can still make sense of the data. Is the key good enough, are the lines slightly different shapes (dot, dashes etc) or do you lose all functional understanding?
Relying on colour to communicate meaning is often a very lazy approach to designing products and it’s something we, as testers, should be acutely aware of and test for.
It’s never right or wrong to use colour to communicate meaning but we should always ask the question; “Will we ever have a circumstance where someone will not see the colour as we have defined it and hence lose the meaning?” Or some other better phrased question.
Here’s a good tool for putting yourself in the shoes of someone with varying magnitudes of colour blindness – http://colororacle.org/
My site under “Normal Vision”
My site under “Deuteranopia” vision – it’s a green deficiency and affects about 5% of males
My site under “Protanopia” vision – this is quite rare.
My site under “Tritanopia” vision – this is very rare.
My web site doesn’t rely on any colour to conduct meaning but you could quite easily see how some websites, graphics and explanations could clearly lose their value when viewed by someone with colour blindness.
Christian Hassa and I are running a free open-space discussion on flexible scope and agile requirements in London on December 6th. We plan to talk about effective user stories, impact mapping, story mapping and so on. If this is of interest, sign up now – we have space only for 20 people.
Well that’s it. Another EuroSTAR done. I’m writing this on the plane home after a tiring few days in the amazing city of Gothenburg, Sweden.
This years EuroSTAR was a really great event.
I saw a great deal of fun and excitement about the industry. I also saw a great deal of standardised thinking, some very shady conclusions from potentially unsound data and a whole lot of reasons to think we’ve still got a long way to go to see deep changes to the way we build and test software. But that’s the sign of a good conference – diverse opinions and much food for thought.
The social side of the event was excellent. There were more social events put on by the organisers (who did a sterling job as usual) and I think the location of the event meant a significant number of hotels were very close by; this kept most people together for the socialising. After all the session track topics are often the fuel for the discourse and deep learning that happens in the bar over a drink.
This was also the first year that I have done a presentation at EuroSTAR. I was deeply worried and very nervous but the presentation went well and the feedback was overwhelmingly positive.
As with most conferences I knew a lot of people from Twitter who I finally got to meet in person. I also met lots of new friends whilst solidifying existing relationships further.
I’m looking forward to next year. DUBLIN! If you do get a chance to go to EuroSTAR I think you’ll enjoy it.
Five years ago, Lisa Crispin and Janet Gregory brought testing kicking and screaming into agile, with their insanely influential Agile Testing book. They are now working on a follow-up. This got me thinking that it’s about time we remodelled one of our sacred cows: the Agile Testing Quadrants. Although Brian Marick introduced the quadrants a few years earlier, it is undoubtedly Crispin and Gregory that gave Agile Quadrants the wings. The Quadrants were the centre-piece of the book, the one thing everyone easily remembered. Now is the right time to forget them.
XP is primarily a methodology invented by developers for developers. Everything outside of development was boxed into the role of the XP Customer, which translates loosely from devspeak to plain English as “not my problem”. So it took a while for the other roles to start trying to fit in. Roughly ten years ago, companies at large started renaming business analysts to product owners and project managers to scrum masters, trying to put them into agile boxes. Testers, forever the poor cousins, were not an interesting target group for expensive certification. So they were left utterly confused about their role in the brave new world. For example, upon hearing that their company is adopting Scrum, the entire testing department of one of our clients quit within a week. Developers worldwide, including me, secretly hoped that they’ll be able to replace those pesky pedants from the basement with a few lines of JUnit. And for many people out there, Crispin and Gregory saved the day. As the community started re-learning that there is a lot more to quality than just unit testing, the Quadrants became my primary conversation tool to reduce confusion. I was regularly using that model to explain, in less than five minutes, that there is still a place for testers, and that only one of the four quadrants is really about rapid automation with unit testing tools. The Quadrants helped me facilitate many useful discussions on the big picture missing from typical developers’ view of quality, and helped many testers figure out what to focus on.
The Quadrants were an incredibly useful thinking model for 200x. However, I’m finding it increasingly difficult to fit the software world of 201x into the same model. With shorter iterations and continuous delivery, it’s difficult to draw the line between activities that support the team and those that critique the product. Why would performance tests not be aimed at supporting the team? Why are functional tests not critiquing the product? Why would exploratory tests be only for business stuff? Why is UAT separate from functional testing? I’m not sure if the original intention was to separate things into those during development and after development, but most people out there seem to think about the horizontal Quadrants axis in terms of time (there is nothing in the original picture that suggests that, although Marick talks about a “finished product”). This creates some unjustifiable conclusions – for example that exploratory testing has to happen after development. The axis also creates a separation that I always found difficult to justify, because critiquing the product can support the team quite effectively, if it is done timely. Taking that to the extreme, with lean startup methods, a lot of critiquing the product should happen before a single line of production code is written.
The Quadrants don’t fit well with the all the huge changes that happened in the last five years, including the surge in popularity of continuous delivery, devops, build-measure-learn, big-data analytics obsession of product managers, exploratory and context driven testing. Because of that, a lot of the stuff teams do now spans several quadrants. The more I try to map things that we do now, the more the picture looks like a crayon self-portrait that my three year old daughter drew on our living room wall.
The vertical axis of the Quadrants is still useful to me. Separation of business oriented tests and technology oriented tests is a great rule of thumb, as far as I’m concerned. But the horizontal axis is no longer relevant. Iterations are getting shorter, delivery is becoming more continuous, and a lot of the stuff is just merging across that line. For example, Specification by Example helps teams to completely merge functional tests and UAT into something that is continuously checked during development. Many teams I worked with recently run performance tests during development, primarily not to mess things up with frequent changes – more to support the team than anything else.
Dividing tests into those that support the team and those that evaluate the product is not really helping to facilitate useful discussions any more, so it’s time to break that model.
The context driven testing community argues very hard that looking for expected results isn’t really testing – instead they call that checking. Without getting into an argument what is or isn’t testing, the division was quite useful to me for many recent discussions with clients. Perhaps that is a more useful second axis for the model: the difference between looking for expected outcomes and analysing aspects without a definite yes/no answer, where results require skilful analytic interpretation. Most of the innovation these days seems to happen in the second part anyway. Checking for expected results, both from a technical and business perspective, is now pretty much a solved problem.
Thinking about checking expected vs analysing outcomes that weren’t pre-defined helps to explain several important issues:
Most importantly, by using that horizontal axis, we can raise awareness about a whole category of things that don’t fit into typical test plans or test reports, but are still incredibly valuable. The 200x quadrants were useful because they raised awareness about a whole category of things in the upper left corner that most teams weren’t really thinking of, but are now taken as common sense. The 201x quadrants can help us raise awareness about some more important issues for today.
That’s my current thinking about it. Perhaps the model can look similar to the picture below.
What do you think?
This is Part 2 of my interview with Anna Sort. If you haven’t already, check out Part 1 of the interview. Anna is a professional nurse who is working to bring together smartphone and video-game technology into healthcare. She is also an Associate Professor at the University of Barcelona, and works both as a gamification and as a serious games consultant.Designing a Better Life Interview with Anna Sort – Part 2
Jonathan: What can go wrong with a system that utilizes technology and gaming mechanisms with a worldwide pool of contributors (aka “the crowd”)? For example, how do you design your game to prevent or deal with the abuse the rules or take advantage of bugs or loopholes?
In our World of Warcraft diabetes add-on we are still deciding if we want the add-on in itself to be fun or not. However, what is clear is that if people wantsto cheat they are allowed to. The add-on is created to fit an exploring environment rather than a “win” situation, it is there for the player to decide whether to play using risky behavior and try what happens if you mix certain things/eat certain foods or to try their best to always “keep in track” with their glucose. It will definitely be exciting as well to see what people will do with the add-on in the end! We are here to learn about how people interact and react to “serious gaming” (using an already existing game for other learning purposes).
Jonathan: What are the biggest challenges you face from a design perspective to create something that people will interact with? How do they apply their virtual learning to their own real lives?
Jonathan: What does success look like for your World of Warcraft Diabetes mod project?
Jonathan: No problem. When you are truly innovating, you don’t really know until you try out an idea, discover what happens, and refine. Moving on, what new thing/trend/innovation are you keeping your eye on at the moment? Is there anything else you’d like to share with us?
For more on these ideas and more, check out Anna’s latest presentation: Video Games and Gamification for Health Care .
If you’d like to help out Anna with her WoW diabetes mod project, contact me and I’ll put you in touch with her and her project team.
For my first blog interview in my Designing a Better Life series, we will be chatting with Anna Sort. Anna is a professional nurse who is working to bring together smartphone and video-game technology into healthcare. She is also an Associate Professor at the University of Barcelona, and works both as a gamification and as a serious games consultant. I find Anna inspiring because she is working hard in the area of mHealth (mobile health) and games for health.
Anna is based in Spain, and graciously agreed to this interview in English for me, and for you, our readers. For more about Anna, check out her blog: Lost Nurse in the Digital Era and these two videos on youtube of her presenting: Designing Games as a Nurse, Gamification of Health Products.You can find her on Twitter here: @LostNurse.Designing a Better Life Interview with Anna Sort – Part 1
Jonathan: Please tell us a bit about yourself. How did you get involved in the games for health field?
After a while I started to look for Masters degrees that would allow me to go into a “techie-nurse” path. I found an interesting Master’s degree called CSIM, which was focused on a multidisciplinary approach to problem solving. I was the only healthcare student in the class, most of my classmates were designers, artists and programmers, but surprisingly 2 of the 8 Masters Thesis projects would have benefited from a healthcare professional, a rehabilitation system and an exergaming platform. In a way that reassured my idea that this “new profession” I wanted to pursue would eventually exist.
My thesis was about the quantity of exercise the children did while playing on an inflatable slide that had a game projected on and kids interacted with through an infrared system (it’s called an “exergaming platform”). I took part in the game design as well as the exercise experiment for my thesis so it was really interesting. I worked on a multidisciplinary team and I loved it. After my master’s I started my career alone, and soon enough I was contacted by Homero Rivas in Stanford, whom I talked about my vision in games and we are currently developing with MIT the first World of Warcraft health add-on to raise awareness on Diabetes.
Jonathan: The research and work that you do sounds fascinating. Can you explain how your work can help make our lives better?
Jonathan: I love your World of Warcraft Diabetes mod project. Can you tell us about this project and your goals? Is there anything we can do to help you?
The add-on is an “add” on the game which you download that changes the user interface. What we have done is add a glucometer on the side that is impacted by the player’s actions, such as running, fighting and eating foods. World of Warcraft has a lot of foods, drinks and alcoholic beverages so it makes the experimentation part very interesting. It isn’t focused on the disease itself, as we are aware not everyone reacts the same way to foods and drinks, and compositions aren’t equal worldwide. We want to raise awareness, and maybe even make new users having youngsters encourage family to play to see what is it like to live with diabetes.
We are not sure what people we will attract and we also are still debating whether we should gamify the add-on or if the game is good enough as-is people will still enjoy the game with the add-on. All the steps should be taken care of very wisely as the amount of research information might overwhelm us otherwise and turn out to be unusable.
How can people help? We still need a good experiment designer to take part of the team, so anything on that regard is helpful. And programmers. Hands are always needed!
Jonathan: What design concepts do you find the most useful for this project?
Stay tuned for Part 2.