jay's old blog

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

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!

Technologies Involved



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

App ecosystem won’t build itself, because developers don’t actually write all the code necessary for the software. A lot of times, it boils down to utilizing libraries that are already developed. If I am building a mobile optimized site, it is simpler and cheaper to simply integrate bootstrap into the code than writing my own mobile optimized stuff.

In this page, the idea is to list out all the technologies, libraries and anything else that we are using. For now, this is all we are using. As more time is spent developing this project, we will update this to list all the stuff we are using.

Windows Desktop App

XAML

C Sharp

Web

Bootstrap

HTML, CSS, JS

jQuery

Android Mobile App

Java

XML

Libraries

Currently none to be mentioned.

[Last Updated February 10th 2017]

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!

Native or Xamarin



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

With the way mobiles are taking over everywhere, it is a given that if some service is not accessible on mobile – either through a mobile optimized website or an app – then such a service might as well not exist. I once went without paying my home power bill because my utility provider did not have a mobile payment option. Folks may not be able to afford a PC but they can afford a basic mobile. Look no further than my experience with the Micromax P290, right here.

Now, the problem with Android is also a good thing about Android. There are so many ways to develop apps for android. You can use the native development tools. You can use web technologies to build the apps. You can also use c sharp to build apps on visual studio / Xamarin. There are just so many options. The thing about using non-native development tools is that, they allow for multi-platform deployment. For instance, I could (mostly) use the same web based code and then eventually deploy on android, iOS, windows phone, windows desktop and of course in a browser.

As the architect of this project, I must make a choice here. Do I go hybrid and target multiple platforms? Or, do I go native and code using native tools and code. If I choose the latter, then, the apps will only end up on android on nowhere else. In an ideal world, sure, I would love to have my apps running on all mobile platforms. Unfortunately, I must look at my target market and I notice that almost all of them are using android devices. Right now, the way things are, mobile = android.

So yes, going cross platform is not really an option. It simply increases cost. Besides, most of our apps will have an equivalent website anyway, which is mobile optimized anyway. All things considered, it’s Native and not hybrid via Xamarin.

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

References



[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 some places which act as reliable online and offline resources for development. In this section, I will list out all the links and books and everything else that we are using. This will others who might follow.

MSDN

Perhaps the very first link that we will use extensively would be MSDN. Everything we need to build APIs and Azure related stuff is all available right here. Years of using it also means, it is that much easier for me to navigate this huge library of knowledge, sorted and arranged for easy consumption.

Stack Overflow

Ah, the second best site for developers online. Anything and everything is available here. I usually start at MSDN, and then head over to stack overflow, and then keep shifting between them until a solution is obtained.

[Last Updated February 10th 2017]

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

Design Tools



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

The tools make or break anything that we are building. Even the best developer can build almost nothing without access to the right tools. Without tools, man = monkey.

Visual Studio

My most favorite tool of all, and hence the very first place. Visual Studio is literally (with Microsoft’s efforts to go cross platform over the last two years) the only IDE one needs to build almost anything. If you are crazy enough, you can even build iOS apps, with some caveats. If you have been a developer for a while, you either love it or you don’t.

In this project, I would be using this mostly for building the APIs and the Cloud portion of the app. I suspect that I will be building the web based admin interfaces also through this IDE.

I love it.

Visual Studio Code

While Visual Studio is awesome, it is also heavy. Like seriously heavy. Building simple stuff, and simply viewing code from a file that came online or from a colleague takes a while in Visual Studio. Most importantly, for web development, we need a simple editor that is superfast. That is what Visual Studio Code is. Fast, light and awesome!

I will probably use this for building and maintaining the user facing sites that will mostly be general information.

Android Studio

I started off by not really loving this (although it is a huge improvement over Eclipse based android development) but the new version is actually better even if it has some insane RAM requirements. Man, it’s not the most efficient IDE is it.

This will be used to build the android apps. However, I will explore the option of building the android app via Visual Studio and if that works, its hasta la vista Android Studio.

Filezilla

For all the FTP related action.

Snipping Tool

Bread and butter of basic documentation that involves screen grabs. Works best with Irfan View.

Microsoft Office

For all the documentation needs, writing and reviewing and generating all the documentation that keeps this project on track.

7 Zip

Yeah, compression and decompression is an everyday activity.

Git – Desktop and non-GUI Tools

For essential version control stuff. More details about version control can be found at these blog posts.

Slack, LAN Messenger and Skype

Yeah, these are the essential communication tools, for outsiders, teams and locally organized folks in a group environment.

[Last Updated February 10th 2017]

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

Back up and Redundancy



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

A lifetime of working with computers has taught me a couple of things, and one of the thing I learnt is the amount of issues that are raised because of poor supply in, well, in the cities we live in. For reasons that are beyond the scope of this document, it is essential to focus a lot on backup systems, and power management is the first big topic on backups.

Power Backup

One must assume from the word go that we cannot always rely on continuous power supply, where we live. Power cuts can go from 10 minutes to an hour to 8 hours to a day. It is simply impossible to assume that something will be available without interruptions. That means, if an essential project is at hand, then, it is best to prepare for every eventuality.

That is why having multiple computing devices (as explained in the hardware section) with at least some of them powered by portable battery becomes essential to keep work proceeding without any issues. That is why, I recommend at least two battery powered computing devices, and not to forget general backup supply to the main workstation PC.

Further, it would also be a good idea to invest in a home power backup system, although, I must admit that those things cost a bomb. If the task at hand is critical enough, investing in a diesel power generator is also a good option, and if the supply of money is good, even essential.

Redundancy

Computing devices can break down for a number of reasons. They could get stolen. Parts could simply stop working, and input devices in particular can die without any warning. All in all, redundancy takes on a brand new meaning because of this.

That is why, multiple computing devices must be hand. Also, don’t skimp out on the quality. If necessary, pay more for less (buy lower spec’d machine but go for the expensive warranty) so that what you have will work no matter what.

Developed code must be backed up in multiple online locations, in servers located all around the world. Offline backup must be made multiple times, and must be stored in multiple locations. Obviously, backup restore must be tested, and disaster plans must be exercised and recovery plans tested and verified when the worst happens.

A recovery plan (tied to a backup plan) that does not work means, you are effectively walking around without a helmet.

Redundancy also means that all the work (at least the one’s that are currently being worked on) are cloud enabled. That way when disaster strikes, you should be able to setup a completely new work machine into your own, assuming superfast internet access. This is perhaps, the most essential redundancy plan there should be.

Other Thoughts

When it comes to backup and redundancy, a certain amount of patience and planning becomes essential. The idea behind having a backup and redundancy plan is not because you expect something to go wrong. In fact, many projects go just fine without any issues. That makes the entire activity related to backup and redundancy an exercise of wastage. This is similar to how some people don’t want to pay for warranty extension because, well, most of the time, the hardware simply works. However, errors are part of any system and such a system manufactured the hardware. So, yes, having warranty makes sense.

Remember this. You might as well have something and not use it, than need it, and not have it.

[Last Updated February 10th 2017]

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

Hardware



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

No development can happen without the necessary hardware in place. Often, perhaps the most overlooked part of any software project would be not having the necessary hardware. This might probably look silly but I am writing this mostly as a guide to other folks who may end up joining hands with me.

While this will be silly, it’s amazing how many engineering students cannot tell the important of having a higher RAM when compared to a slower processor. So yes, from experience alone, I can tell that a section on hardware would be most useful in a world filled with the uninitiated. I am dividing the hardware stuff into multiple sections. That’s because there are so many different hardware units used on this, and they each deserve a separate section. Obviously, I am not using any physical servers, with all the online data storage and processing handled by cloud based services, from Microsoft Azure. More details can be found at this location.

Project Related Hardware

This is something that applies to the entire project. Whoever is in charge of managing the entire project’s hardware must be aware of the following stuff.

Individual Developer Hardware

This is something that is required by the developer to hang on to. A developer who is poorly equipped is a developer who is worthy enough to code is what I believe.

Personal Computing

I recommend at least three different computing machines. A main machine that will do the real heavy lifting. A second machine that is reasonably powerful, and good enough to act as emergency development machine. Lastly, a simple device for basic stuff like documentation and doing administrative tasks. We are looking at minimum of three machines, with each of them acting as a backup to each other. Three is not the final number, but it is a good number to start with.

Here are the essential hardware specs for developer.

Main Work Horse PC (not laptop)

Display of 27 inch + Display of 15 inch. If possible, an additional third monitor if the computer can support it.

RAM of 16 GB. 32 GB RAM, if the motherboard can support it.

Processor, any of the i3, i5 and i7 processors. Any generation is alright. Newer the better.

Onboard graphics card is good enough. Dedicated graphics card is simply a drag on the power supply, especially when you have to live with constant power cuts.

Power Backup. At least 4 hours of backup, for the entire setup (at least two monitors).

Wireless Keyboard and Mouse. No wires for us please.

The Second Machine (the actual laptop)

Standard 15 or 14-inch display. Not FULL HD, not a problem.

8 GB at least. i3 or i5 processor (don’t go for i7 because that will be a power hog) is alright. If you can get Core M, that is even better.

Dedicated graphics card won’t do. Onboard are powerful enough these days and an extra graphics card can consume more power.

Optional wireless keyboard and mouse, although most developers do just fine with the built in keyboard and trackpad. If you are a touch typist, you know you should go for the former.

The Third Machine (a hybrid laptop, touch screen)

Bare bones 2 in 1 laptop running windows with detachable keyboard. Yeah, this will be mighty useful for administration tasks, presentations and even some emergency web development stuff. The cheaper the better. Further, these devices can run for over 8 hours for sure.

Mobile Computing

Two android mobiles, hopefully with a FULL HD display and 3 GB of RAM. These can be extremely useful for testing and even some emergency presentations and general productivity.

[Last Updated February 10th 2017]

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