[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]
There are different types of users who will be using the app
ecosystem. I can broadly divide them into two categories.
Front Line Users (Someday I must come up with a better name
These are users who actually use the service. Rather, these
are the consumers, everyday folks who visit restaurants and those who own the
restaurants. We must make the (hopefully correct) assumption that their choice
(or rather, their only computing device) of device would be an android
smartphone. I must also assume that tablets are dead. I wrote
about it earlier. That means, optimizing or building a separate android version
optimized for tablets is an unnecessary effort. I would like that, building a
version for tablets would be nice. They have a much larger real estate which
opens up many possibilities.
That actually brings up the issue of accessibility. This is
something I have decided to take rather seriously, and that is why, there is a
separate article on this. We will revisit this topic later.
Returning back, so yes, right now, I only envision two types
Restaurant Patrons – These are the folks who visit the
restaurants and pay for food and stuff.
Restaurant Owners – These are the restaurant owners, who
then proceed to see what the patrons are doing at their restaurant.
In both cases, I am looking at an android app itself, and
then proceeding to build a web version of the same. In all probability, the web
version of the app may never be released because it’s easier to manage users
via app than via the site. It reduces workload and also just makes sense.
People love apps, although they don’t love updating it as much. Then, there is
the magic of notifications.
Behind the Line Users (yes, definitely a better name is
Behind the line users are those that are sitting at the
offices, and that means, they do have full access to a working computer. That
means, we can assume access to an actual computer, with a screen, keyboard and mouse.
Here, I have two options – a desktop app (it needs to be installed) or a web
app with no mobile optimization.
If it is going to be a desktop app, then it will be built as
a UWP that will run only on windows 10. I don’t see any reason why an app needs
to be targeted for anything below windows 10. At the same time, what if the
user is using a Linux (yes, it happens) or Mac (yes, this can happen too. Some
folks insist on paying twice of what something is worth, if only to get the
apple shaped light :P). Going by that logic, it is prudent to start off with a
web only app. If it comes to it, it is possible to wrap that web thing into a
desktop app, which should solve the challenge of having an actual desktop app.
That is the cool thing about windows app development. Things
are a lot more open lately, making life easier. With that in mind, there are
three types of users.
Operation Users – These are the folks who will monitor the
service status of the cloud service, which acts like the back end for the whole
thing. These are also the folks who will look at Error reporting system.
User Administrator for Restaurant Patrons – These are the
folks who manage restaurant patron accounts.
User Administrator for Restaurant Owners – These are the
folks who manage restaurant user accounts.
As work on the project continues, more user types might be
created. However, I think these are the users where it all starts. I will see
soon enough. Using the available tools of asp.net with MVC, it is possible to
simply build one web app destination and customize the views based on user
privileges. Yeah, I think I should dunk the entire desktop app thing, and build
one single app that runs in a browser. That will bring in true compatibility
across windows, Linux and Mac. Heck, if I play my cards right, it could also be
[Last Updated February 10th 2017]
Follow me on twitter,
for more updates. Thanks!