Hi this is the daily overpass, my name is Eric and I make apps!
Now today, I want to talk about creating app specifications!
Ok, so today I want to talk about documentation and writing a project specification.
Because if there's one thing us developers really really love, its
documentation. Actually that's not true, we actually do like documentation!
Developers like to document as much as - at least
really good developers - like to document a lot. And not so much in terms
of like Word documents and things like that, but to document their code, to make
sure that everything is clear and concise for the next person. A bad
developer just charges away and nobody could read what they do
afterwards. This is one of the reasons why good code is important.
Well I want to talk more about creating actual documents for a
project. So - and this is something I've always been very hot and cold about -
if you've ever worked at a large corporation or like when
I was working in investment banks, we'd always have several
projects, and they were never really that big, but there was always
a full time project manager on them, and they would...
they would go and start typing away, and they would put together these huge
documents, or like a whole series of documents. We would have like projects
that would have 10 documents that I don't think anybody ever read, but they
looked really good sitting on a shared drive someplace. Or
they'll come to you before the project and say "Eric, you know.."
or they'll hand over this big 200 page specification, and I have had 200
page specifications and even bigger, or they'll print it all out and
hand it to you and go ah you know here you go "here you go, I've been working on that till
four o'clock in the morning. I didn't think I was gonna get it done in
time!" And you're like "wow, time well spent, thank you very much" and
you sort of take it away you think "I'm probably not going to read it", but you
don't want to tell them that because they want to feel important.
Aand they'll do stuff like UML documents in there -
diagrams - or maybe some use case diagrams, which it depends
on the developer, but you know a lot of the times the developer, once they
understand that they don't really need that level of documentation
or they won't even bother to read it because it's just
too much. So when I say that I'm hot and cold with documentation, I
don't like documentation that is written for documentation sake, and that happens
a lot. I mean, even when we work with clients sometimes we will put
documents together that are not. I think that document should be useful.
You should think about the audience
that are going for it. To contrast that like I've worked on
projects where we've had no documentation at all, and that's really
really hard. It's really hard to guess what other people want. Like as
an app developer working for clients, you'll get things people say, stuff like
"hey Eric, I'm looking for an app that's a cross between uber, flappy birds,
and tinder. How much would something like that cost?" And you're like, "I just
need a little bit more information. Which in your head, is not the same as what's
in my head". And that's one of the things why writing a specification at the
beginning of a project is so important. It's something that we do every time we
do a new application. So we don't just say 'can you do like such-and-such?', no. We
have to put something together that makes it so like, what's in my head is in
the developers head or the designers head. So we can share that
same vision. The same with clients, you know, clients very rarely come to us with
documentation. Sometimes they do, which is nice. They'll come with wireframes and
stuff like that, but a lot of times they'll come to us,
we'll have a chat, we'll sit down and a lot of times I'll just sketch out
diagrams and stuff in my notebook, I'll come home and I'll put it into
a document. So let me just show you kind of what I mean here. I'm not
talking about 200 page specifications with a virgin history and
everything like that, although that kind of depends on the client. Usually I'm
talking like three to five pages, just a few wireframes.
So here's one of the first specifications I did for for one of our
own apps. This is one for ear spy. So what I did was, I hired an Indian company and
I started out doing it myself, but I realized I wasn't gonna get
anywhere, so I hired someone to do it and I thought I better put something
together so they know what I'm talking about. Because a lot of
times when you're dealing with the software development company, you're
talking to one person and that's not the person doing the code, and they're
to convey that to somebody else, and you have this telephone thing going. So you
need to put together just a small documentation,
nothing complicated. The goal is to convey information. So here's
the one for ear spy - it is really simple because it was such a simple app idea,
a really simple flowchart here with two things. I just want the audio
that's coming in through the microphone to go up to the audio - that's all I want
to happen. And then I put together some wireframes really quickly with Balsamiq.
Balsamiq is one of my favorite tools for wire framing. I know there are
other better ones out there like Proto.io and there's so many out there,
but I just I really like the simplicity of Balsamiq, even though it's
really old but I know all the shortcuts and everything, and I know
there's better ones out there but one day I'll start using those. So you
know a little thing here is just, you know, what it should look like. The layout
and then the bit of markup saying what everything does.
What kind of in-app purchases we're gonna have and what the menu options
should be and stuff like that, and just really really simple. Now when we do
games, it's a lot more complicated. So the first games that we did were the
language learning games - so the bubble bath games which we still do. We use this -
we have a whole series, we have about 23 different languages that we've
done this for, but this was a first specification. So this was something
where I sat down and I thought "how are we gonna do something like this?
How should something like this work?" And it was my first game so, you
know, our games are very simple. This is something that some of you guys
might point out, our games are not very complicated, they're very simple,
so basically an overview, kind of what the game should do, the purposes
of the game, how it should work. And I think how it should
work is probably one of the most important things. You want the flow of
the application to be brought in as early as possible. So first we see the
splash screen, and then we see the title screen, and this is just me with graft
paper and a ruler and trying to draw. Like my duck here right, this is
why I hire designers! So click on start, click
on high scores, click on instructions and then what each one here
says. And then I go to the category screen, and then I go to levels
and then what each level should look like. And here back in the early versions it
was actually in a bathtub rather than having a scenic background.
And the bubbles have flowed up. I tap on those and I tap on this, and I get the
health, the level pages and just a very simple description of what everything
does. It was much more complicated than ear spy even though it is a very
simple game. And then you have the early levels, what it should look like
and then kind of a summary of what each level should do and how they should
change from the previous level. And we only had ten so it was very
simple to specify. Then some ideas of other apps that kind of have that look
that I like, and this is one of the things that I think is really
difficult in terms of doing design, especially when you're doing it for
clients - it's really hard to know what they have in their head or what kind of
things they like aesthetically. So a lot of times
I'll say "is there another app that you see that you think you like
that style of design. We're not going to copy that design, we're not going to use
their images, but we're gonna use that as a basis for how this thing
should look going forward" And this is what I provided them in the
beginning, and then because I'm a technical person I also
put how I want the data to be stored in XML and all that kind of stuff, and then
you know which steps we should do and I also put in stuff like 'in the future it
would be nice to have this, just so that when we're coding it we can know that,
we'll allow for that. So, how would we structure the data? We say
in the future we might add special bubbles or something like that. Here's
another one for Eye spy. Because of the success of ear spy we did another one
with video, but it was kind of okay and you can see it in a browser.
Really, really simple specification. And then we started, because
we're working with our own internal team we use Google Documents now, so we don't
I don't use a word document so much anymore. Only when doing client
stuff. So I prefer using Google Docs because it's really easy to collaborate
with the developers. And I know office 365 does a lot of that stuff now,
but I find it really clunky, at least I did last time I used it which was just a
couple years ago. Here I could just put together a quick documentation
saying what the app is that we have, my app idea. If it's a
form-based one I use Basalmiq - put together a few few specs, kind
of how it should work and what the design should look like.
Here's one for viaduct. Viaduct is a project that
we're working on at the moment. And this one can give flowcharts how things
should work, maybe some mind maps, some stuff, just get everything into one
document. Chinese spy - same kind of thing where it
was like a language learning game, but I want it to be spy based and kind of some of
the things that I would think. Some other language categories,
the kind of text I would have. It's just sort
of stepping through my initial ideas of how it should look. One of the beautiful
things about this is that I can do something like this, and that gives the
designers...we have Sandee who's been on the team for two and a
half years, she could look at something like this and come up with a bunch
of different options and they always look way better than mine!
But I just kind of say where things should go and how
it should look. A lot of times a finished product doesn't look anything like that.
And again a lot of times, because we're using a Google Doc, we don't have to
worry about version history so much like we would if it was on the
g-drive somewhere in some organization. But we can just go here and and make any
comments and it's easy to notify somebody of a comment by just put
their Google+ name on there and then they'll get an email saying you were
mentioned in this comment, and then they could just go through it and do all that
kind of stuff. So anyway, that's basically how we do things where we
specify new projects. Oh and also, I'll add Google, sometimes I'll go
find images from google images, which you can't use in your app for the most part
if they're copyright, but you know, if it's an internal document so it doesn't
really make that big a deal. And that kind of helps. The whole goal of the
document is just to get everybody on the same page, so any ideas that I have goes
into this document. They might have better ideas and then we can modify the
document. In the end, we have something that we're all working off the same
thing. So anyway, I'd be interested to hear what you guys do in terms of
specifications. I know if you're one man show a lot of times you don't need them,
but even when I'm doing my own stuff, even when I'm coding stuff to myself,
sometimes I'll just sketch it out in a notebook before
I actually do it just so I can get an idea of what it should look like, rather
than coding it and then moving everything afterwards. So I'd be really
interested to hear how you guys do this kind of stuff! And that's it for today
I'll talk to you guys tomorrow!