jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Project TD - Day 59 update – Core Tech – Web api module and migrating to new blog



UPDATE 2!!!!

Alright, my new blog is now up and running. Find it here - https://thesanguinetechtrainer.com 


UPDATE!!!!

Okay. This is weird for me. For the last few days, BlogEngine.NET (the software that powers this blog) has been acting crazy. I have spent a good chunk of time troubleshooting (after all, I am myself a dot net developer and this thing was built using dot net, and I have come to a realization that, there is not fixing this. No one else is facing this issue.

I dont think it is a connection issue to the web server, because the blog itself is running just fine.

I dont think it is a database issue, because the blog does not use a database.

I thought there would be a easy way to export my blog to elsewhere, but nope. This blogengine software is not popular enough to merit that.

and, since I cannot create new posts (fortunately, existing posts can still be edited and updated) I am updating an existing post. I suppose I should be happy that at least this is working.

I am currently exploring both wordpress and medium as my next blogging software. I like the look of medium, so I will probably go with that. I still dont know how I will move all the stuff from this blog to the new medium blog, but right now, I need a place to write and publish. Or else, I will lose my mind. and fast, at that.

--------------------------------------------------------------------

When discussing the API engine, I put a flowchart in place that dictates how I would work on the different modules of the entire app ecosystem of project TD. Then, I further broke down the api engine into simpler modules, which I have discussed here. Here is that list, for reference.

  1. 1.       Build and Deploy an API
  2. 2.       POST and GET to the API
  3. 3.       PUSH and PULL from the API to the Data Service
  4. 4.       Google Maps API on Android, Web and iOS
  5. 5.       Facebook Login API on Android, Web and iOS

Obviously, I realized that some changes were needed, and here is the revised list of the simpler modules.

  1. 1.       Build and Deploy API (this includes the POST, GET, PUSH and PULL from the above list)
  2. 2.       Android app that works with the above API.
  3. 3.       iOS app that works with the above API.
  4. 4.       Web app that works with the above API.
  5. 5.       Google Maps API on Android, Web and iOS
  6. 6.       Facebook Login API on Android, Web and iOS

From the above list, 1 and 4, are completed. I mean, in software, there is no such thing as completed, but it is completed to acceptable levels. This blog, talks about 1 and 4, and I will move on to item 2/3/5/6 next.

As I have already decided, much of the back-end stuff, that is the API, is being built using .NET and that means, I get to use my favorite language c # for all of this. That much is done. I am using web api 2 technology for this. Since I don’t wish to manually create the tables for this service, I am using entity framework, version 6, to act as the agent between the api app and the database. For the database, I am using Microsoft SQL server, and for the hosted web app where the api would live, I am using an IIS server, powered by Microsoft technologies. All the server components are hosted on Microsoft Azure, and the cost, so far, (at the time of this writing) less than 500 rupees per month. Of course, this is a test server, and the load on it has been kept at extremely low levels. I am sure the actual cost when the full api ecosystem launches will be in triple or even quad digits.

While building this api, I ran into Knockout JS. I hadn’t used that one before. I also ran into attribute routing, which is a fun feature and I am surprised that it is a recent addition. I sort of assumed that it was always there. I also learnt about action names, but I think attribute routing sort of makes it redundant, but it is good to know it is there. Of course, the current api only communicates in text data, which might become a problem later when I wish to deal with multi media. However, from what I heard, the necessary modifications should not be a problem.

I am not currently satisfied with the way the web app works. It takes raw data, JSONifies the data on its own before consuming it. The web api does have components that return data in both raw format and JSON string format, so perhaps at some future time, I will build a web app that works with the JSON calls. For now, though, I will stick with the default web app built using Knockout JS.

The api is living on the cloud, and I have now completely abandoned the (soon to be retired) classic azure management portal. The new azure portal is sort of heavy on the system and it has this sliding interface which makes it difficult to work with. Especially as more azure components are loaded. However, it has all the new stuff, and for good or bad, Microsoft has been pushing the new portal for at least 3 years now. I guess, it is time for me to go with the change. I still don’t like it, but it is the future, so I am bending backwards for that.

As always, my tech guru, mika has been wonderfully helpful while building this. I want to thank him for his help, and hopefully, I will return the favor someday.

Alright, enough of the diary writing. You can find the two repos related to the above components, here and here. You can find the web app demoing the api, running at this link. Obviously, the repo has all the comments I can put and relevant links and stuff.

Alright, that is all for now.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Project TD - Day 41 update – Core Tech For The First Batch of APIs for the API Engine


[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]

Earlier, I have written extensively about the design technique that I plan to follow to build the API Engine. The API Engine itself is a collection of APIs. For the last few days, I have been analysing the APIs that will make up the first batch of contribution towards the engine. I noticed that there are some essential tech components that they need to use to make it work.

Going by the design that I put in place, this is the second bubble from the API design titled as ‘Identify all Tech’.

So, here is the full list of tech’s that are identified to make this happen. The blog post image above lists it.

  • Build and Deploy an API
  • POST and GET to the API
  • PUSH and PULL from the API to the Data Service
  • Google Maps API on Android, Web and iOS
  • Facebook Login API on Android, Web and iOS 

I will of course, follow the design plan, and repo the above stuff, tutorial it. After that (these steps will take a few weeks to complete), I will finally have some serious unit testing to work upon.

As they say in the good books (mostly, there are no good books that I refer to. It simply me using them as proxy :P), exciting times lie ahead!

Follow me on twitterfacebook and instagram for more updates. Thanks

Project TD - Day 28 update – Design for the Modules of API Engine



[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]

I have already blogged that the entire app ecosystem depends on what the heart pushes and collects. The heart being the API Engine. I have written multiple times that the whole system must be modular so that parts can be replaced and re-engineered if something goes wrong. Or, if there is an opportunity to make things better tomorrow, then, that option should be readily available.

To that effect, I have come up with a design plan (pictured above) that should drive all engineering efforts towards the API modules. It’s a simple and plan design, but it should be enough to help me. Obviously, it is subject to further revisions if the occasion should call for it.

Pick an API

The API Engine is but a collection of API calls running on a single API server. On one side, it provides access to facilities to end users. On the other side, it has the necessary access to the underlying database. As of now, 12 API calls that would form the first batch of API services that will be part of the API Engine.

The idea is to pick up, one API service (each of them will have their own designs) and then start working on it. First step would be figuring out the design which means, illustrations, finite discussions about its usability with the stakeholders. Once the design is confirmed to work (to the best of data available), then we move on the technical part of it.

For instance, for the patron app, there would be one service that pushes the restaurant data to the server. This would be one API call. So, I would start off by designing the work flow. Show the workflow to as many people as I can (my, mom friends, my tech mentor, the many students who are under charge and of course, random strangers) and collect its feasibility. Use this feedback data, and design the final workflow.

Identify all tech

At this stage, the design and the flow of activities of each identified API has been done. The API design itself is completely independent of the underlying tech that will actually power it. For instance, the design is like I wake up in the morning and decide to have breakfast. The actual activity of eating breakfast might involve many things. I could have a pack of biscuits. Two packs of milk. A luxurious breakfast at my folks place. Or go out and pay a decent amount and generous tip at my favorite restaurant. As you can see, the decision to have breakfast and actually having it, though related, are quite independent of each other.

Similarly, the design is always independent of its implementation. It’s part of the modularity and replacability thing I keep going on and on about. Here, I will be thinking only of implementation and not question the design choices.

Earlier, I mentioned an example API service that pushes data from the patron app to the cloud. So, I need to figure out all the technologies that will make this happen. It would mean, I need to build a web app, android app and a iOS app that has a simple button. This button would collect data (that mean, I need to figure out how to collect data on all these platforms) and trigger a cloud push on button press. Like this, I break down the design into individual components and see how the code would actually work for these things.

Repo it

Once the tech part has been figured, the next part is pretty straight forward. I have already promised that a lot of stuff related to the project would be open sourced. Anybody can use it non-commercial uses. So, I will push the code of the web stuff, the cloud things, the app solution, everything on a public repo.

Tutorial it

The repo will have the code. As is my standard practice, I write pages and pages worth of documentation within the code. However, it helps me (and my career) to have some tutorials that point to the approach I took while converting the design into runnable code.

Unit Testing

Once the repo and tutorial is done, I need to check the individual fitness of the resulting module. This will ensure that the unit itself is independent and will involve writing dummy external connections.

Integration Testing

Once the unit is confirmed to be fit to work, next comes the part about integration. I have to check if this module will work with the rest of the modules. I also need to check to make sure that the system won’t come crashing down when the module dies or goes corrupts or simply stops working for some insane reason.

Once the integration testing is done (if it fails, I will probably have to restart at the design stage and work down from there), I put the module aside, and start over by picking up the next API service to work on.

Rinse and Repeat

This part is useful when, at a later point, if some new tech is introduced which will make things faster. Or perhaps some technology on which the app depends gets rebooted and revised. For instance, Microsoft might replace their existing mobile data service with a new one. Or, Facebook might implement a new login system. There are so many gears moving here man, anything can change.

Anticipating change and being ready adapt is the only way I can keep this engine relavant and allow it to evolve.

Note about Sketchbook from AutoDesk

I have upgraded from hand written illustrations to using the Sketchbook app by AutoDesk on the iPad. For the purpose of drawing, I am using an Amazon Basics stylus. I must confess, there are some serious advantages to using this over the hand written thing. Obviously, the free app has certain limitations. For instance, I can only have 3 layers (which is alright but annoying) and I cannot select components (which is the biggest handicap of the free version). Eventually, I will have to get the pro membership, but I have to evaluate this system first. Once I am satisfied, I will kick things up a notch with the pro membership which provides tools for desktop and android as well. It is fairly inexpensive and should be useful.

The Amazon stylus is extremely basic, and there is a learning curve involved here as well. I feel that it is good enough for now. If this art design thing goes to the next level, I will probably spring for a Wacom stylus for a better control over the designs. For now, I am still trying to figure out the stylus.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Project TD - Day 19 update – Moving from Requirements Planning to Design



[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]

Aha! It took 19 days for me to wrap up the requirements planning. I have been using the whole Island – Volcano – Ships and other stuff – Ocean as an example for my ecosystem. I think that makes sense because everything that happens in software (or any machinery) for that matter is a reflection of real life itself. That is why, it is only prudent that I (with my limited intelligence and even more limited imagination) use some real life stuff, especially nature stuff, as an example eco system.

Right then, enough with my babbling. So, the requirements planning is done. A huge chunk of details related to this is documented at this link, creatively titled, Requirements Planning. Of course, nothing is ever done when it comes to any planning. Yet, I am happy with the stuff documented so far. I feel confident enough that I have enough stuff to move to the Design stage.

The design stage will be elaborated upon I future blogs posts. May the force be with me.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Project TD - Day 19 update – Designing the Design Process



[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 components.

Sketches

Technologies To Be Used

Tutorials

Repositories

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.

Sketches

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 it.

Tutorials

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 me.

Repositories

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 multiple tutorials that don’t link to a code on the repo. It’s a fault I am trying to fix going forward.  

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, continuing my 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. Thanks!

Project TD - App Ecosystem – Day 16 – Designing the App Engine and API Development Status Dashboard and User Account


[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]

I have learnt (perhaps the hard way) that a project without a deadline, is not a project at all! Sure, the deadline may get extended, and the project may die away. That’s the negativity in me speaking. Of course, the deadline could be met, and the project may actually reach something that resembles completion. 

Project TD needs to hit beta phase in less than 10 months. The official launch is less than 6 months after that. I am racing towards a deadline, and that means, I need to pick up a starting point. The requirements planning is all good and fine, but at the end of day, some programming needs to be done. The more I think about it, the more I feel that the API Engine is where it all starts. 

That brings up the question -  what is the API Engine? Everything and anything that works with some service is an API. For instance, the app ecosystem will use the Facebook provided login system on the end user side. The admin folks will use a Microsoft Identity library. I do not think I will bother with providing alternate login systems for end users. This does limit access to some extent. For instance, users who don’t have a facebook account might choose not to be part of Project TD. 

That should be okay. As I have already mentioned, this entire project will be open source non-commercial usage. So, if someone wants to include some other login system, the design is modular enough to allow another developer to latch on Google or Twitter or email registration based system. I must understand my limitations here. For the foreseeable future, this entire ecosystem will be built by me. If there is an opportunity that can be exploited and work load can be reduced. The login system, at least for the end user, I am going to limit myself to Facebook. I like Facebook. The Graph API is simple to use, works on almost any platform and it has the color blue. 

That’s the story with the login system. And the above Facebook login system is made possible because of the extensive login API’s that the Graph API (Facebook branding for their API stuff) provides.

Anyway coming back, the API Engine will be the collection of all the API calls, the entire ecosystem will make. That includes the many apps that will be used by the restaurant patrons and the owners, the admins, the ops folks and other roles that might be included as the design evolves. The API Engine is the only way the users can interact with the database, which stores the data. Now, the API engine (which is essentially server that listens and responds to calls from the users) is the store front for all the apps. On the other side, the API Engine interacts with the database, processing all the stuff that the calls are asking for. 

This allows for a breakdown of responsibilities, which is essentially, the whole point of modularity. Thanks to this, it is possible for me to design redundancy around the database. Build backups, replace when data goes corrupt (or gets hacked) and replace, hopefully on the fly. Since everything is broken up into pieces and connected with bridges. The source and destination don’t really care where the bridges actually go on the other side. All they care is that, on their side, the bridge is fine. 

This API Engine, is like an island at the very center. A huge island that has everything. Below the island (the API Engine) is the underwater volcano. Think of this as the database. Now, this huge island is surrounded by small water things like tiny islands, ships, ports and boats. All of these folks need something but they cannot talk to each other directly (that is whole point because boats die over time. We don't want the bridges to die with them, bringing the entire system down with them). They are all connected to the island, and everything goes through it. The island, on its own is nothing without the underwater volcano (the database). 

Thinking backwards, the center of this whole ecosystem would be the island and the volcano under it. Once these two are in place, the rest – boats, ships, sea gulls, ports, sharks and dolphins – will start settling around it. Everything in the system can be replaced of course. The island, volcano, the hundreds of boats, ships and sharks. Redundancy is the name of the game man!

As a consequence, I am now spending all my time designing the list of APIs that will from the first set of API calls, which together will become the API engine. As with the island-volcano thing from above, the API engine is useless without a database. So, along with the API engine, I will also have to design the data storage system. For both the database and the server that will respond to API calls, I am going with Microsoft Azure services. I have enough experience dealing with Microsoft Azure, and it has every possible thing imaginable to build and deploy pretty much every aspect of the ecosystem. There are alternatives (Amazon comes to my mind) but I simply have had better exposure to Microsoft services, and despite their higher charges, I will go with that. 

As I design (and then build the API Engine and the database), I figure that I will need an API dashboard that will keep track of the API calls currently being designed, developed, tested, deployed and available. This should become extremely useful to allow the stakeholders to keep track of what is happening, and obviously, what is not happening. 

The dashboard will be the choice of tool for the operations team whose job is to make sure that the system is working as designed. This also means, they need to be provided with the necessary information to deal with problems when they occur. Then, when the issues are fixed, the data should reflect the resolution. This also, will be routed through the API calls, and will be part of the API engine. The smart thing to do would be to separate the API Engine to multiple parts. However, if the entire system is backed up (and it is simple enough) then it makes sense to maintain just one engine, and then have backup engines ready to go when things go bad. 

The interesting thing here is that, the island and volcanos are separate. Each of them have copies of them, waiting in the pipeline if disaster should strike. If I split the engine into multiple parts, the redundancy maintenance factor will go up by that much. For now, it seems wiser to simply have one system to maintain, instead of multiple specialised systems. 

Next up, I must pick up the design tools which is where my new iPad and the pre-owned printer comes into the picture. I will talk about that in the next blog post. 

Follow me on twitter, facebook and instagram for more updates. Thanks!

The UI Challenge and Tackling It – Mom Mode



Technology is about making life better. Better is a relative term. Technology in itself is a vague term. For instance, fire was the first invention. Wheel is another one of those things that we take for granted. However, fire and wheel changed the very manner of living of our ancestors. Fire made food better. Wheel made transportation faster. Fire and Wheel make things better. In essence, technology should make life better.

These days though, it’s all about app this and app that. I was exposed to technology at a very young age. I was fascinated with computers, the first time I played that ‘break the bricks’ MSDOS game when I was in my 6th standard. For years now, I have gone completely digital and can get things done in minutes, which would have taken hours otherwise. Take grocery shopping for instance. Except when I have company, I don’t like grocery shopping. To and from the store is like an hour. Actual shopping about 30 minutes. Then, at the counter and other unexpected things, another 30 minutes. We are looking at 120 minutes for a simple activity of getting supplies.

With online, I could get this done in 10 minutes. 5 minutes, if I am fast, which I usually am.

That is why, as a tech guy, it hurts me when my own mother cannot make the most of these facilities. Two weeks ago, I had a discussion with my mom. I told her that, as a gift, I could get her a nice Samsung Tablet or an iPad. I told her that she could get a lot of everyday things that she does – like take an Uber or Ola to the doctors or meeting friends, shop for groceries, listen to the radio and watch television. As of now, she uses me as a proxy for all the above online stuff. I wanted to make her independent of me, in case I am not around.

At first, she was all up for that idea, but then, she gradually withdrew. Eventually, she said that there is no possible way she could figure out how to use all these facilities. I know my mom, and she is not the ‘I don’t want to change with the times’ person. She taught everything I knew and I know she is the one person who supported me during my engineering, MBA and then when I decided to go all independent consultant on my career. The issue was not her, but the gadget itself. I realized that the apps, be it Uber or Ola or Skype or Big Basket are all designed for the ‘internet enabled’. They are not designed with folks like my mom in mind.

There could be many reasons for this. However, reasons are not how technology works. Or innovation. People don’t innovate because there is a reason to do it. At least for me, technology is about making life better. My mother’s life is already better because her children are internet equipped and are providing her with most modern amenities. However, she still has to rely on me. It’s like she is watching a movie, but instead of the reading the subtitles, she needs me to read it for her, and only then she can enjoy. This is the current system, and it’s good. It can be better though.

That is where I decided that at least my apps, starting with Project TD, will have, what I would like to call, ‘the mom mode’. I don’t know how it will work or how it will look. What I do know is this much. I will do everything I can, to make sure that my apps can be used by my mom, and moms who are in similar scenarios.

I will update this post, a few months from now, if I actually do this.

You can get more details about Project TD, right here.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Choice of Technology for API



[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]

At the core of any ecosystem is the API system. The API is consumed by the apps, that are in turn used by the users. They could be the apps used by the operations team. Apps used by the administration team that oversees user content that is pushed. Apps that are used by the restaurant owners and of course restaurant patrons. All of them will interact with the cloud storage that actually serves and takes data over a collection of API calls.

That is why, the choice of technology used to build the API is important. As much as possible, the whole eco system will take a modular approach to development. If some technologies should die (which happens more often than you might think), we should be able to remove things and replace them without affecting the rest of the components in the ecosystem.

Although the API system is also modular (at the end of the day API calls are but simple web routes) and follow the remove and replace principle. Still though, rewriting the API itself will be a huge task. That is why, if I am going to choose an API technology it must be something that I will keep for a long time and only replace it if I have no other choice.

There are quite a few technologies out there that can be used build RESTful API’s – Node.js, PHP, Python, Rails, Dot Net and Java.

First up, I am not a big fan of PHP. Because, with all due respect, PHP HELL.

That leaves other technologies of which I am not going for Java because, I have already invested a lot on c sharp and I am not going to spend an equal amount of time on Java, unless it is a matter of survival.

Python, Node.js and Rails are things that I am familiar with but it makes sense for me to leverage on my existing dot net skills, which is where DOT NET based API building comes into the picture. As it is, the project uses a lot of Microsoft technologies (except for the android mobile, almost everything else depends heavily on Microsoft related technologies) and using the same thing for API reduces total effort time.

However, as far as planning goes, if it comes down to using an alternative, I would side with node.js. It seems to be the one that is much more modern and well document among other alternatives. So, that would be the alternative. Yeah.

[Last Updated February 10th 2017]

Follow me on twitter, facebook and instagram for more updates. Thanks!

User Types – Operations and Administrators and Consumers



[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 for this)

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 of users.

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 required)

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 mobile optimized.

[Last Updated February 10th 2017]

Follow me on twitter, facebook and instagram for more updates. Thanks!