Hot on the heels of 0.24, I’ve released Boobie Teeth 0.25. In this release, I’ve gotten the mini-map function implemented the way I want it. The mini-map is now transparent, and (if you care about Game Maker internals) is now based on draw commands rather than a View. The code that draws the mini-map is based off of an example I found on the Game Maker Community forums, by a developer who goes by the handle Supertramp.
Download from the Releases page, and play it!
Boobie Teeth 0.24 is out today. Mostly refinements in this release. Probably the most notable new feature is the wave motion. In the shallower part of the level, wave motion will be felt; dive deeper to get under the waves. I also made the level spawn event fair by having the new fish be created in a position avoiding the player, thereby avoiding unfair deaths. Some additional code refactoring under the hood.
As always, you can download the game from the Releases page.
I went to the Cleveland Videogame Developers meetup tonight. It ended up being a special meeting for me, because I got to meet Dan, who was one of the founders of the meetup, but hadn’t been to a meeting in about three years.
In talking to him, I learned that he also was instrumental in helping Mike Substelny set up Lorain County Community College’s Computer Game and Simulation Design department. It was in Mike Substelny’s class that I got my start with Game Maker, a year ago. Since then, I have started out my first game project, been invited to contribute technical review on an upcoming book on Game Maker, spoken about my experiences at the Notacon conference, and in doing so I’ve realized a 30-year childhood dream and become the person I’ve always wanted to be.
It’d be easy to say I did that all by myself, but really, if it weren’t for Dan, everything else I’ve done wouldn’t have amounted to anything. For everything else I did, and as much as I’ve always wanted to make videogames, it didn’t finally come together until I took that class last year. So, however indirectly, Dan’s partly responsible for me getting my legs under me and able to move forward.
After telling him about the things I’ve been up to, Dan told me that it sounded like we had a lot in common. We both aspired from a very early age to design and make video games, we both had taken a long path in life to becoming programmers, and we both have yet to complete and release our first game. That last part threw me for a loop, but it’s true. When I asked him what games he’s made, he said he had a couple of projects that he was working on, but hadn’t released anything yet. [It seems like everyone in Cleveland Game Devs says that! :( ] I just hope that I’m enough like him that some day I run into someone who, although I had no idea, I had some small yet significant part in their life turning out the way they’d hoped it would when they were six.
I have completed my Safe Zone extension for Game Maker, and made it available.
Altogether, here’s what we now have:
SafeZone.gmk – the original proof of concept, which creates a non-wrapping, square safe zone around the protected object.
SafeZone2.gmk – improved proof of concept, which creates a circular safe zone which wraps around the protected object.
SafeZone5.gmk – Further refined, now the function incorporates parameters which control whether the wrap applies in the vertical or horizontal directions, or both, or neither.
SZ5.gml – the raw .gml of the script code written for SafeZone5.gmk
SafeZone_1_0.gex – The Safe Zone extension, v.1.0, based on the SafeZone5 code.
SZ_GEX_demo.gmk – a demo project which incorporates the .gex rather than scripts.
This extension could use further refinement, as it assumes that literally anywhere else in the room is safe to place the new instance. If you have solid objects in your room, or multiple other objects that you do not want to collide with upon spawning the new object, this obviously will not hold true. But for certain types of games, such as single-player free-flight games, this should be quite useful.
I got a working demo of a safe zone spawn which works with wrapping rooms. I refined my technique for determining the safe zone, and now instead of being a square, it is circular.
I like this approach, it works pretty well. Basically, rather than trying to literally “wrap” the safe zone around the edge of the room, I create five safe zones. They are at protected(x,y), protected((x+/-room_width), y), and protected(x,(y+/-room_height)). In my instance_create loop, I merely determine whether the new instance’s candidate x,y location is within some distance of any of these five points.
The current script I wrote up is working, but it just uses a distance in pixels. My original approach calculated a distance automatically, based on the size of the objects’ sprites, and a padding factor, which I liked. I’ll likely create a version of this script that works that way in the next day or so, when I have a moment, and then package the whole thing up into a .gex for distribution.
Until then, the .gmk source is already up on the site.
One other note: One of the annoying things about Game Maker is that when you write a function, you can only return a single value. In most other languages, you can create classes of objects, which can be used to encapsulate as many values as you like, and return the entire object. Game Maker kindof lets you do this, but you have to create a Game Maker object, which it a bit more literally object-like, in that it carries some baggage with it. I think that my function would be more useful if it simply returned a set of (x,y) coordinates without actually creating an instance there. But I can’t return both x and y — a function can only return one value. I could return the id of an instance of an object, however, and simply spawn an empty, spriteless object at those x,y coordinates, and allow the developer to either change that instance into whatever kind of object they needed there, or else grab the x and y values from the object and destroy it. It’s an idea I’m toying with, not really sure which way to handle it is best at the moment, but it’s fun to play around with ideas.
In Game Maker, it’s non-trivial to spawn a new instance, avoiding collisions with existing objects in the game. This can make it tricky to create games with “fair spawning” so that the player isn’t automatically killed when a new, randomly-placed instance springs into existence.
It isn’t terribly complicated to work around this problem, thankfully. Basically, the approach I take is, knowing the x,y coordinates of the instance or object that you want to want to avoid collision with, and the size of that object’s sprite, you can define a “safe zone” around the instance you wish to protect.
I’ve whipped up a quick demo in Game Maker 8, showing a technique which seems to work pretty well. This is a very simple illustration of the approach, and could be refined further to handle wrapping the safe zone around the edge of a room, or to handle enemies of randomly varying sizes. To make it easier to understand, I’ve actually created an object to represent the “SafeZone” . This is unnecessary, as the dimensions involved can simply be calculated on the fly, using the right GML.
At long last, I’ve gotten back into developing Boobie Teeth. I’ve released 0.23, available as always on the Releases page.
In the two weeks leading up to Notacon 8, I worked on Boobie Teeth roughly 16-18 hours/day, making great progress, but had about burned out by the time I got 0.22 ready for the presentation. I really like pushing on a project like this, where I’m interested and motivated, but probably can’t sustain more than 12-14 hours of focused effort a day for very long. I had intended to take the next week or two off from the project and focus on some other things — housecleaning, getting ready to start a new job in May. For a number of reasons, this summer has been full of misfortunes which kept me out of advancing the project as I dealt with various crises. But things have settled enough, to where I can now resume working on it.
This release was actually mostly done between 4/16-4/17. I had a few ideas from playing 0.22 that I wanted to put in quickly during Notacon weekend, and got it done quickly. There are only a few changes in this release, not as much as I probably had intended when I started 0.23, but since so much time has passed between then and now, and I’m not entirely sure what else I might have decided to include had I kept working on it — there are a number of things on my list that I might have thrown into this release if I’d kept working on it, but at this point I’m not too sure what they were.
I briefly considered just ditching what I’d done for 0.23, and going back to 0.22 and start over again on 0.23, but I decided in the end to keep what I’d accomplished in 0.23 and just put it out, then start 0.24 with fresh direction. The additions which I did make to the game seem to have been complete, so rather than drop them and add them back later, it makes more sense to keep them.
I think that in 0.24, I’m going to focus on a few performance optimizations so the game will scale up more before dropping frames. It’s about at the limit of that right now, in my demo level, which won’t do if I want to do a few things that I want to do when the game advances to the next level. I really need to be able to put more objects on the screen at once without things slowing down.
This past weekend (7/29-7/31) I participated in my first Cleveland Give Camp event! This was the second year of Cleveland’s Give Camp, and I had heard about it too late to participate in it last year. Once again, it conflicted with the PyOhio conference, which I went to in 2010, and hope to be able to again, so hopefully event planners will try to do better to avoid conflicts in the future. Not that it’s always possible
I was slightly apprehensive about how it would all work out, being my first time doing it. It didn’t seem like it would be possible. In just 72 hours, I was supposed to join a team of developers whom I’d likely never met before, and collaborate on a small IT project on behalf of an Ohio nonprofit organization who had a worthy project. The projects were evaluated ahead of time so that the Give Camp organizers could select candidates who could be helped within the constraints of the event’s format. This was a well planned weekend, and we were able to be productive. In fact, all 22 projects were successfully completed this year, up from 14 last year. In total, over $500,000 in professional services were donated. Burke Lakefront Airport and LeanDog generously hosted the event, which was funded by a raft of corporate sponsors. Volunteers camped out and worked all weekend, and in exchange we got fed and thanked and made to feel appreciated. This seemed to be pretty fair.
Most of the projects were to create web sites. There were a few that were mobile applications or databases. Of the web sites, most if not all seemed to use WordPress. I’ve been using WordPress for my own site for more than a year now, and have liked it. I like it even more now! WordPress is so powerful, flexible, and easy to use. I may gush about that later.
In our opening meeting, we were assigned to teams. In my team, we had a project leader, and a couple developers, and I served as the team’s designer. When we sat down to go over the project, it took me a few minutes to realize that eyes were on me to tell the developers what to do; I had expected there would be a little more direction from the project leader, but after we had dinner on Friday and sat down together to meet with our customer contact, Lisa, we just went around and briefly introduced ourselves, and were let go.
Lisa told us about her organization, Adaptive Sports Programming of Ohio, and we took a quick tour of their old website. I spent about five minutes clicking links and skimming, and quicker than I knew how, I came up with a bullet list of the top 5 or 6 categories of information, and proposed that we try to re-organize the site’s content in that fashion. I noticed that much of the site’s content was geared toward linking to other resources. This is an older approach to web strategy, and seemed to me a bit outdated, a bit reminiscent of the early Geocities-era world wide web, when the manually maintained index of Yahoo! ruled. Maintaining all that content was a lot of work — checking for dead links and whatnot, and, I reasoned, was not effective in the current era, since most people find content on topics they’re interested in through google or through social networks. I proposed dropping as much of this “resource” content as the customer felt comfortable, and putting the priority into emphasizing the other categories, most importantly: donations, how to get involved, and events that their organization was directly involved with.
To my surprise, and to everyone’s credit, there wasn’t any resistance to this idea. I was a bit worried that Lisa might feel like I was about to destroy “her baby”, or simply disagree about the importance or purpose of various parts of the old site, but she was ready to put her trust in us with us right away, and the rest of the group seemed to like my proposal as well.
Throughout the weekend, we (and I emphasize “we”) quickly made decisions together in a most expedient manner, without egos butting heads or any of the typical bad human behaviors that I’ve seen over the years which have wrecked teams and projects. Someone would have an idea or see a problem, get someone else’s opinion on it, and propose a course of action, and it would either be adopted readily or if someone else had some additional thought on it, this was added to the original proposal, and we went with it. I never felt like I was pushing on anyone else on the team or stepping on anyone’s toes. It was great. The couple or three wrong turns we made along the way didn’t cause us any real harm as a result, and when we changed course both abandoning the old idea and adopting its successor went very smoothly.
One of the concessions we did have to make was that we weren’t able to migrate all of the content from the old site over to the new site. By the end of the weekend we realized we would not be able to get 100% of the new content for the site up by the time we were finished. Too many decisions needed to be made about the content, which were best left in the hands of the site owner, which is what we did. We ended up building a good, but mostly empty, new “house” for her to move into.
In retrospect, our project might have gotten more accomplished if we’d had someone do a content inventory and figure out what to do with it all. My initial idea that we could simply re-organized and adjust emphasis according to the priority of the site’s missions was a good thought, but as we got deeper into the content on the old site, it became apparent that simply copying and pasting it was not going to be effective. The old site had a lot of content on it, not all of which was going to come over. The volunteers on the team couldn’t make decisions about significant amounts of it without the site owner.
I had the thought late Friday that once we got the new site up and running on WordPress, we might be able to get Lisa trained on managing content in WordPress, and have her get familiar with it by bringing over the content herself after we got her started. This didn’t end up happening, either. There was too much else to do, Lisa needed to be involved in other decisions, and her availability for the weekend wasn’t as total as the rest of the team. Much of the content needed to be re-thought, not just re-organized. We didn’t have a dedicated copy writer on the team, and even if we did we might not have known what content to re-work and what to ignore without direct involvement from the site owner.
I think we can consider what we ended up with a successful IT project. We produced a redesigned web site, built on open source, which promises to be easier to manage in the future, and handed it off in “move-in ready” condition. It’s certainly an improvement over the infrastructure that they had in place previously.
There was a good bit less coding on this project than I would have guessed, going in to the weekend. In fact, I gauge our success in no small part by how much we did not need to code to get the project done. Code we wrote was code that someone would have to maintain, and the way Givecamp projects work, there is no provision for support once the weekend is over. We didn’t want to leave Lisa stuck with a project that would need ongoing code maintenance, and no one to do it for her. Accordingly, a lot of the things we could have considered doing for the project, we dismissed in favor of finding an off the shelf solution that we could mash up to create what we needed.
This was definitely the right way to go. The amount of customization we needed to do in order to get the site working and looking the way we needed was not zero, but we did keep it minimal. What customizations we did make were documented and handed off to the site owner. It was all, as far as I know, css, php, or javascript — all of which are interpreted, and thus can be modified without need for recompiling. We spent the bulk of our time looking for plug-ins and figuring out how to configure them, testing things out, and fixing this or that with the least amount of customization that was needed. This was a good application of the “what’s the simplest thing that could possibly work” principle.
We did not elect to take a TDD approach, but it is really not apparent how we could have had we wanted to. With so much existing code provided for us in the form of the WordPress application, the themes, and plugins, embedded youtube videos, and so on, there really wasn’t much of anything to write a test case against. I’d be interested to hear from someone more experienced in WordPress and TDD to provide some ideas on how to take a TDD approach to building a WordPress site. If you want to use TDD, do you need to start from the ground up, or at least find a stack that will lend itself to the TDD approach? When you’re dealing with platform built out of interpreted code, and with the final interpretation of html, css, and javascript are all up to the client, what value do your test cases have?
I love WordPress for how easy it is to use. It has sufficiently abstracted the web stack that you can do a tremendous amount with it, without having to write one line of code. It is well maintained, and yields web sites that are easy to maintain. That said, it still does not guarantee optimum results. It takes skill and knowledge to deliver that.
At the end of the weekend, the 22 projects that the Givecamp volunteers built were presented for all to see. While all 22 projects were completed, and about 18 of them were web sites, most if not all of which were built on a WordPress platform, I did observe limitations of what can be accomplished in a single weekend. Without singling any project out, I could see some design issues in the final products that were completed by Sunday afternoon. I could only observe the most obvious design problems — bad typography, disproportionate layout and whitespacing. And granted, typography on the web is still in a pretty horrible state which CSS3 will hopefully address. I don’t mean to come off as negative or nitpicky. Still, there were a few sites which I saw that had obvious problems that probably could have been fixed with a few minutes (at most, hours) of CSS tweaking. Even our own site was not 100% perfect, and I’m confident there is no such thing as a weekend web site that can’t be improved with a little more labor.
Not every team might have had the eye or the skill or the time, and I’m certain that every group delivered a product that was better than what it was replacing (which in some cases might have been nothing at all) and was appreciated by the recipients of our giving. But I hope that future givecamps will have more designer resources to go around. And copy writers! In fact, I’m tempted to say that the WordPress ecosystem is so successful at solving the developer side of the problem that future givecamps might well be better off with more copy writers and editors than developers.
Given how happy and successful everyone seemed to be at the end of the weekend, and how… well, Dilbertesque the real world seems to be, I had to wonder if somehow all the success story I was seeing around me all weekend wasn’t somehow an illusion. Like, why do real companies have such a hard time with IT projects? I’ve never had such an easy, happy time working on a real-world project as I did this weekend. And I can’t really chalk it up to having the right people. No complaints about our team, but we were just put together and had never worked before. We weren’t an established, well-oiled machine.
My biggest worry about the effectiveness of an event like Givecamp is that, no matter how much you can accomplish in one weekend, ultimately the long-term success of these projects is in the hands of the organizations we gave them to. We can give them a great start, but without proper maintenance and attention, any website will quickly languish and become irrelevant And without a web-savvy content maintainer, that ain’t gonna happen. No matter how easy and intuitive a developer thinks they have made something, there’s always non-technical people whose purpose in life seems to be to prove the cynical adage about nature building a bigger “idiot” whenever an engineer thinks they’ve idiotproofed something.
I’ve seen proud development teams hand products off to users, who manage to break things in some novel and heretofore unforseen manner within seconds too many times to expect that this should somehow not happen here without good reason. I think one such good reason is that WordPress is good, mature, and healthy. But not every project was done in WordPress. At least two were done in C# with MS Access backends and one was done in iOS. I’m really curious as to the viability of the Access apps.
I was talking with event organizer extraordinaire, Mark W. Schumann, about this, and he’d had some thoughts along these lines as well. We’re both really curious to measure the long-term success of these projects. Because, let’s face it, as good as it makes us feel to donate a weekend and do good deeds, we want our efforts to be as effective at solving the problems they were designed to solve six months or a year from now as our efforts were appreciated when we handed it off. It’ll be interesting to see what we can see a year from now. I’d really like to see some quantified measurements next year.
I’ve been having a rough time of it lately, at least judging what I’m normally accustomed to when it comes to my normally very convenient, easy, underappreciated life.
Just so you know, I’m typing this post one-handed. I’m doing about 30wpm now, which is pretty good, but I’m frustrated that it’s not the 90wpm that I normally do. Hahaha, no, that’s not why… I had a bicycle accident about three weeks ago, in which I broke my left humerus, just below the shoulder joint.
This was to have been my comeback ride — for about a month prior, I wasn’t able to ride my bicycle due to pain caused by an inflamed sciatic nerve, which was aggravated by an overly ambitious bike ride that caused me to have some lower back pain.
I normally don’t write about personal stuff in this blog, as the intent is for the web site is to be a professional portfolio and blog about software development, IT, and other things related to whatever it is I’m making my career out to be. But, as I have realized as a result of my experience in putting together my presentation to Notacon 8, I feel most complete when I do not separate my professional life from my personal life. I’m not very happy when I compartmentalize my life, working 9-5 just to earn a paycheck, and leaving work behind when I’m done with my day, and having the balance of the day left to pursue my personal interests. I want to make a unified life where nearly everything I do is geared toward achieving personal goals, and my professional goals align and merge with my personal goals to a great degree.
So this might not be the most technical of blog entries, but rest assured it ties in, as all aspects of my life tie in somehow to the work that I do and the experience and qualifications that enable me to do it.
I have been disappointed at these setbacks that have hampered me for the last two months. I had been enjoying bicycling with my friend Rachel, who had gotten me interested in hitting the road a few times a week, and had been feeling great as a result of the exercise. But it seems like every time I make an effort to get into shape, something happens that prevents me from continuing my program and I lose the progress I’d gained until I get my life in order enough to start again. This has happened countless times in my adult life. And then when I try to make my comeback after patiently waiting for the inflammation to subside enough to be active again, misfortune strikes again.
I got pretty depressed about the prospect of losing my whole summer to being sidelined with this stupid broken arm. But this lasted only a few days. The experience of mending is still ongoing, but so far has been very unlike what I might have expected. Although it is not something I would have wished for, I am the sort of person who delights in surprises, particularly when they have something to teach me. And I have come to the point where I realize that there have been things worth observing and reporting coming out of this experience.
So here’s what I’ve learned:
When I fell off the bike, I didn’t hear or feel the bone break. I wasn’t quite stunned by the impact with the road, but it definitely staggered me, the way a body slam does. I knew almost immediately that there was something wrong with the arm, and didn’t want to try to use it. But the injury was numb initially. Not tingly numbness, but just not feeling much of anything at all numbness.
Before this happened to me, I would have expected any broken bone injury to be constantly acutely painful. I was surprised that in my case, it wasn’t. Perhaps it would have been for a worse injury than I sustained. I recognize that in my case, the type of fracture I had was perhaps one of the best possible ways to break a bone, if you had to break a bone. There was no displacement, no compound fracture, and a clean break. It only started to feel painful about 30-40 minutes on after the injury.
This gave me adequate time to do things that I needed to do in order to survive: pick myself up and get out of the street, and assess my condition, for example. Even when I did start to feel it, it wasn’t too bad unless I got jostled or bumped.
The pain was very useful in this way. It communicated to me what I needed to know, namely that I had an injury, that it was fairly serious, and then it largely got out of the way and let me take care of myself. If I did anything that might have made the trauma worse, the pain increased sharply, giving me immediate feedback that what I had done, or what had happened, was not something that I should allow to continue for any length of time.
From a User Experience perspective, I find this very instructive.
A few months ago, I watched a video of a talk entitled “Stealing From God!“, which in retrospect might have put me in the right frame of mind to pick up this lesson. The talk is worth watching in full, but in summary it’s about bio-mimesis as an inspiration to the design of technology.
When it comes to systems I might design in the future, I’ll definitely be taking this into account. Very often users complain about a shitty user experience by calling it “painful”. It’s a metaphor, but usually means tedious, repetitive, or time-wasting. Normally we designers who care about User Experience just want to eliminate any pain so that users will never have to experience it. I still think that this is a good goal. But I now think pain has something to tell us, and what it can tell us is important, and that a user experience designer can learn from it when s/he encounters it.
My advice is this: Don’t simply seek to avoid any and all pain. When you first experience “pain”, explore it. Find out what it is telling you, and if you’re the designer, ask yourself if that’s the right message, or what else or how else can you communicate more effectively. Delve into it, listen to it, appreciate it in its subtlety, learn from it. Once you understand the pain fully, then you can work effectively to avoid it altogether, or to make the “pain” as beneficial an experience as possible for the user.
It’s still best to avoid painful experiences if at all possible in the final design. But where “pain” is actually useful, it may be possible to incorporate it into the design in such a way that a user actually appreciates it. The pain experience that I had through breaking my arm was so much more useful than my typical negative experiences with computer software errors… in a strange way I find myself almost welcoming the experience with the arm — not that I would rather break my arm than experience a stupidly designed software error condition! But I can appreciate the beauty of the user experience that the bone fracture pain has given me much more than I can appreciate certain repetitive nags and modal dialogs with inadequate information and poor choices that I often see when using a computer.
Common, seemingly familiar events can still surprise when they happen to you. Due to the location of the break, the ER couldn’t put me in a cast. Before this happened, I thought I pretty well knew what “the deal” is when you break something. I assumed walking into the ER that I’d be walking out with my torso half encased like a plaster or fiberglass cyborg, stuck in an immobilized position for months, and emerge from my chrysalis months later, atrophied and unable to move through my usual full range of motion. In my mind, broken bone == cast. Experience has taught me otherwise.
It turns out my experience will be nothing like that. They put me in a sling. Three weeks after the injury, my doctor tells me I’m doing well and the sling is now for comfort, not necessary to keep the arm immobilized. I can already use my arm to do light tasks. My effective strength is greatly diminished, and my range of motion is greatly restricted, but other than an ugly bruise, to look at me you wouldn’t think I had anything wrong with me, leastwise a broken bone.
As I’ve been healing, I noticed early on that if I ate a lot of protein, particularly red meat, the pain in the fracture site lessened. Often this effect was greater than the effect of the pain management drugs that the ER prescribed for me. I was surprised, but I understood immediately that it makes a great deal of sense for the body to be wired to work this way. My body needs more and different nutrients to mend a fractured bone than it normally needs, and the reward of reduced pain for eating the right (apparently) stuff is a great example of positive feedback. As a result of the reduced pain, I learned immediately that I needed to eat more of certain foods. And the pain would return if I hadn’t eaten recently enough. Again, more lessons to learn from the pain user experience. If I wasn’t paying attention to the pain, I might have just taken more pills to dull the pain. The pills, as it happen, dull my appetite, and would have created a negative feedback loop by not eating what I need in order to heal quickly and properly.
Instead, I’m amazed that three weeks after the injury I’m able to do so much, and am ready to begin physical therapy. I hear that it’s going to be painful. I’m acutely interested to learn what new messages I will be able to read in the pain to come.
To ensure that I eat well while I’m in this crucial healing period, and to keep myself from going stir crazy while I’m stuck at home (my doctor told me I shouldn’t drive, so I’ve been working remotely from home) without much human interaction, I sent out an open invitation to about sixty of my friends, asking them to pick a day to come over for dinner, which they would have to provide for me and they would also have to do the dishes afterward.
Surprisingly, a number of my friends were happy to take me up on this invitation. Tonight, my friend Jennifer came over with chinese food. Jennifer works with accessibility issues for disabled computer users, and is rather obsessed (I guess the polite term is passionate) about it. Perhaps because she’d come straight from work, perhaps also because she knows I’m an IT guy who is into design issues especially as they intersect with user experience issues, we ended up talking a lot about accessibility.
Jennifer clearly knows a ton about accessibility, way more than I do. I get what she says without trouble, but she’s way more familiar with the problem domain than I am. As a designer, I think it’s important to account for accessibility when designing the user experience.
Developer is a generic word — usually it means “programmer” but it also incorporates “designer.” And of course, developers are not always — in fact not often — good at both programming and good at design.
It’s hard enough for your average/mediocre programmer-developer to come up with a good UI to provide a high quality experience to the user because the average programmer-developer doesn’t know much about design, or usability. Developers who are decent at usability can design an OK user interface, but often forget about accessibility issues.
Actually, forget might be too strong a word. I sympathize with developers, so allow me to soften that a bit. They’re often resource constrained and unable to devote resources into providing accessibility. And because they seldom get to work on accessibility, they tend to not “get” accessibility.
For that reason, I think it’s a good idea for developers to “try out” various disabilities.
I’ve learned a great deal from not being able to use my off-arm at all for two weeks. I found I can do almost everything that I can normally do, but I have to take a different approach to it. It definitely slows me down. I have to think and plan actions and break them down into multiple steps that a one-armed person can accomplish. Not having the off-arm to assist my strong arm slows me down a lot more than you might think — two arms working together realizes synergy. I can carry a lot more with two arms together than I could with each arm doing its own thing. And the off-arm assists the strong arm in innumerable ways. If I needed to accommodate a one-armed person in some future project, I’d at least have some idea about what approach I’d take.
If I were to head a User Experience group, I think a great team building exercise would be to have each member try out being disabled while at work. Each person in the group would randomly select a disability, and then they would have to live it at least while at work, and I’d encourage them to continue living it at home. And not just for a few hours, or a day… say, for a week, or two. To really get an appreciation, you need to get to where you almost forget what it was like not to have the disability, but that would take a long time. A compromise “tryout time” will do well enough. During this time, they would observe carefully their experiences, and note where they found difficulty or obstacles, what approaches they took to deal with those obstacles, including asking for help. And they would be tasked to identify changes to their work environment that would make their disability easier for them to manage, and implement solutions. Needless to say, they would also have to do this for whatever projects they happen to be working on while disabled.
After going through that disability, the employee would put it down, and take on another. We’d have blindfolds, noise-cancelling ear protection, wheel chairs, arm and hand restraints, maybe special glasses to simulate colorblindness, whatever we could come up with. On a regular basis, employees would be encouraged to talk about their experiences as a “disabled” person and share what they are going through, what they are feeling, and especially how they are dealing with everything.
After the employee had gone through each disability that we could simulate, they would no longer be required to try them out, but could still revisit a disability if they wanted to go back and look for more insights. I have a feeling the best user experience guys would do so regularly.
This isn’t just a good idea for people who design the things that we use — it’s a great exercise for everyone.
For one, it makes you appreciate the things you can do but take for granted.
Second, it prepares you for the possibility of living with a disability at some point later in life if that should ever happen, as it commonly does for so many.
Lastly, it would help foment sympathy and caring for people with disabilities. So often disabled people aren’t thought about at all, and when we’re confronted with the need to accommodate their needs, too often people resent it, and and up resenting the person as well. This is terrible, but avoidable through the right experiences, learning, and appreciation.
In a way, I’m almost glad that I broke my arm. I still wish I hadn’t, but I’m grateful for what I’ve learned from it.