A new life for vocabup.com: MARKETING

I reached a new stage in developing the vocabulary enhancement app. I come to a point to stop development for a while and do market research and marketing. As in case of vocabup.com I am marketing and development guy in one person and I realize now, that programming does not make the whole show. The previous work was good and I reached my goal to build a reference app showing state of the art software development implementing the progressive enhancement and mobile first webdesign principle. The result is a very accessible app that can be enhanced up to a native equivalent offline app easily. The app can even do the balance act to run without JavaScript, a characteristic of Accessibility. The effort to make the app offline is far less than to write an app for every platform. All I have to do is to write/extend the client side database layer and master and apply Application Cache. As I chose a dedicated node.js webservice as the view layer I do not have to change my view code, be it for server side rendering or client side rendering whether via Ajax or IndexedDb, since this layer can be executed on server and client. I was not under time pressure and could think in the very long term and strategically and so I was able to build the jack of all trades software, or lets say the jack of all platforms and use cases.

Look at the performance test results for the vocabulary app exercise page! There are still some minor issues. The database queries for this page are complex in order to present the user an intelligent word quiz and so it takes time for the server to send the first byte to the browser. The thesaurus pages can let users wait for a second too. There are words having up to 75 definitions each of them having synonyms, sample sentences and domains they belong to and many semantically related definitions which for their part have synonyms and sample sentences. The WortNet 3.1 database is like its name says a net, so the information you get about a word is complex and relating to other words. That is what make this thesaurus and dictionary so interesting but also stresses resources. But the majority of the vocabup.com pages load fast, like that page. I decreased the page size by compressing all the big JavaScript and CSS files and even the HTML is compressed in the case of the blog pages or React apps. Now the vocabulary app can be accessed even when the data transfer rate on a mobile device is low. That means my website is also accessible to many countries which has poor infrastructure. In Germany there are many spots where mobile services has no chance. But my app will still respond quickly! And the app fits in all displays in contrast to many old and established web apps.

I had a problem with React. This does not shed good light upon React and I was worried first. I still did not get an answer from the React guys on stackoverflow yet. Maybe I post it in the React forum more prominently. On the other side I am satisfied with a workaround in the meantime. As I have a marketing phase now anyway I will return to that problem later.

In order to start marketing I integrated a wordpress blog into vocabup.com. The strategist that I am I have different goals by writing a blog. First is search engine optimization (SEO). Search engines love text and if I want to be found by them I have to tell them how good I am at knowing and providing ways how to improve vocabulary. But it is more than search engines. I read some pages about improving vocabulary. Read, read, read, they say and write. Having a strong vocabulary is said to be the most important factor for having success. Writing really helps myself to dive into the topic and find my niche in the market. And while doing this I can praise what vocabup.com can already do for vocabulary enthusiasts and gather ideas how to improve and direct vocabup.com. Google Analytics will show me which keywords are best to concentrate on and where competition is low enough and what the visitors are interested in. Finally I can enter the market and develop the software very focused and thus efficiently. So blogging is a very cheap and efficient way to get into the market and try keyword combinations out and get feedback.

Tutorials like this helped me to find an approach how to incorporate a wordpress blog into vocabup.com seamlessly. An obstacle was the unexpected behavior openshift adds to committing and pushing a git repository to the production server. Normally you would tell git which files to leave out from committing and pushing by the .gitignore file. My aim was to just leave different wordpress installations on development and production server and maybe just check in and deploy the theme. Git supports this workflow and can ignore files that are not in the index. But Openshift deletes ignored files from the remote repository on the production server. Openshift clears the remote repository at first and push the resources freshly each time you git push to production. So I just had to write a post deployment action hook, which creates a blog directory and places a symbolic link into it which points to a persistent directory where I have my wordpress installation now. But know that!

Progressive Enhancement of a datadriven offline Web App

If you want to develop a data driven offline web app, you will nowadays use IndexedDB, since WebSQL is deprecated. In the native world where things are perfect you will create a download for a SQLite file, which can then be queried. In the HTML5 world you have to populate the indexed database in two steps. At first, the data must be downloaded and then this data has to be inserted via Javascript. This is somewhat cumbersome, since it lets the user wait until your highly efficient Javascript code managed to provide the offline feature. If there are a few MB of data to be inserted and there are millions of records to be created in the object stores of the database, Javascript takes its time, especially on a smartphone. I made an insert test with about 800.000 records on my macbook pro with SSD and a powerful i5 processor and it still took up to two minutes. The same procedure took 15 minutes on an android chrome browser. I did not test all different browsers on all different platforms yet. This is another problem to solve, since not every browser has the same implementation of IndexedDB. You see, while developing web apps is strategically a good choice, you start developing the data driven offline web application with a handicap. How to solve this problem? This is where progressive enhancement comes into play. Like every principle there are advocates and opponents. Despite of having more code to write to progressively enhance the user experience of a web app I can only see advantages. Concerning our problem populating the IndexedDB on the client side, why not let the user request the content from the server, until all needed data is available on the client and then query against the local database and update the page via Javascript. Web users are used to get data from the cloud be it via ajax or by a page reload. How happy are they if from a certain moment on the app works offline. They feel like on an airplane, that took off!
There are other advantages of progressive enhancement. It is important for optimizing your website for search engines (SEO). Search engine robots which visit your pages to retrieve content to their indexes are not willing to interprete Javascript. So this is another reason to let the website work without Javascript. Javascript might really enhance the user experience. But if your content can be retrieved by good old reloading the page from the server, the search engine robots have much to eat and love your website. You can make your whole database available for search engines and in this way generate many thousands of web pages in the index. This increases the number of potential visitors enormously.
Another reason to enhance a website by Javascript functionality instead of depending on it is the increasing complexity of Javascript code. Since Javascript became such a popular and important language to build websites, more and more code will be written and more and more errors are made. If this code breaks, the functionality is still available and there is more relaxation to fix it.
As a side effect is the web app usable for the 1% of users who have willingly or under constraint disabled Javascript.