[Ongoing series of blog posts to inform
potential developers, users and (hopefully investors) about this new app ecosystem
I am architecting, designing, developing and deploying. More details at this page]
Now that the requirements planning is all done (at least to
an acceptable level), it’s time to finalize the design process. The design
process is crucial. I have always believed that being a developer (which
include being a designer) is always better than being a programmer. I have
spent considerable ink on that topic while discussing Uber
and self-driving cars. That means, a good design is the only way to ensure
that the idea leads to become an usable service.
That means, I need to first design the actual design
process. My design for the design process would include the following four
Technologies To Be Used
Everything in software development is a cyclical process.
The more time you spend revising stuff, the more you find flaws in it. The less
flaws one finds, the more confident one becomes at its design. A solid design
means less flaws during actual development (where the actual app ecosystem is
coded. I always make sure that I run my design through a lot of people. God has
blessed with access to individuals from varied backgrounds, and most of them are
people who know the techie kind of person that I am. So, when I approach them
with what I want, they don’t get weirded out or act surprised. In other words,
I can collect an endless amount of feedback from folks who are tech wizards to
those who technical achievement is forgetting their personal phone’s PIN LOCK.
It all starts with illustrations, drawings, doodles and
anything else one might call creations. I have given myself access to a lot of
drawing tools. I have got the good old fashion pen and paper. The premium
notebook for scribbling. Of course, I have my iPad with a nice Amazon Basics
stylus. In the future, I will probably invest in more expensive drawing tools
but I must balance my ambitions with the budget for this project.
One reason to start with sketches is the universalness of
visual things. My mother can understand. My students can understand it. My tech
mentor can understand it. Random people I meet on the road can understand it.
Anybody can understand it. Over the years, I have learnt that no feedback is
less important. Sure, some feedback might be useless, but then again, the
greatest products have been built by the silliest of inspirations.
I have already concluded that the app ecosystem has the API
Engine at its heart. The API Engine is but a collection of APIs, and each
API would have a design connected to it.
Technologies To Be Used
Once a sketch has been finalized, the next step is to start
adding real technology to reflect the corresponding actions. I mentioned
earlier that that each API would have a sketch attached to it. Once that is
done, it would be essential to connect the different components of the sketch
to the technologies that are used.
For instance, at its simplest, I would need to build an API
service that would take some data, and push it to the database. For this, I
would need to code the API, put it on a server, design the database and then
connect the two. I would need to list out all this, and code the stuff out of
Me just learning how to convert the sketches into actual
technology components is not enough. I must write tutorials related to it.
While I am an architect, I still make a huge a chunk of money through training.
I must have a collection of tutorials that will help me bolster my tutorial
portfolio. Otherwise, one of the main benefits of this thing will be lost on
Of course, all code must be pushed into a public repository
that supports tutorials. A tech tutorial without supporting code is not that
cool. I will be the first to admit that I myself have written
that don’t link to a code on the repo. It’s a fault I am trying to fix going
Each design will go through the above steps, and hopefully
there is enough for room for all possible flaws to show up. The end result of
the above process will be modules, which I would like to consider as ‘ready to
use module templates’ or RTUMT. The actual development process (which comes
after the design is over) will utilize these RTUMTs. Hopefully, since the
RTUMTs have already been vetted at the design stage and the coding stage, the
actual development will put a lot of focus on integration of these modules,
efforts to keep the entire design modular. This will allow me to remove and
replace modules as newer and better technology should become available if the
app ecosystem survives the first year of operation.
Of the five stages of the app ecosystem development, I
imagine that the design stage to be the most extensive. I have vowed not to
start the actual development (which will eventually lead to the beta
launch) until the entire design is completed. That means, if necessary I am
happy to spend an additional 6 months fine tuning the design rather than jump
to development with a half-baked design.
It’s going to be a long ride man.
Genius is eternal
patience - Michelangelo
Follow me on twitter,
facebook and instagram for more updates.