A list of quality indicators we could find on an application or web site

When we write a project specification document, we write functionnal and non-functionnal and other sections. As I want to communicate to my peers and sponsors the level of quality, I thought of creating this list of indicators.


Web application quality attributes

  • Frontend should adjust to the user browser (tablet, computer, phone) “Responsive” (already partially in place)
  • Frontend URIs should express what they represent for future/possible conversion to REST service endpoint
  • Frontend response time should be as quick as possible using optimization techniques such as assets minification and non-blocking javascript
  • Code “Domain” (language) should illustrate user intent
  • Frontend to use W3C valid markup following HTML5 recommendations in a “Progressive enhancement” manner;
  • Logging system should declare application state and intents and provide helpful feedback (e.g. “User jshmoe logged in from… Montreal Quebec.”)
  • Front-end error message should be using terms that speaks to the end user
  • Error message and notices should not break layout
  • All message and user read text should be without spelling mistakes or bad translation


Frontend as quick to load as possible

Among most recommendations and references about common user frustrations is the time a web page loads.

The idea is to basically push to the queue and forget returning a page back as soon as possible.

Other key aspects are graceful degradation of javascript, functional site even with javascript errors.

Most importantly. The portal frontend can be deployed in any number of instances, with only one address, and be completely transparent to the user.


Your opinion

What else should we also include in such a list? I agree that it is not complete as much as a W3C recommendation is. But I believe it is much good in a context of a project outline to explain details you are taking into account while evaluating.



What is Cloud computing when it is related to web application

During the discussion, the contributor persisted on knowing what would be considered and thresholds to use some kind of push-button-scaling.

Knowing his context, a unzipped install CMS with a buch of plugins I felt the urge to explain that there is not always need to get a bigger server capacity. Here is an overview of what I mean when I talk about cloud computing and continuous integration.

The E-Mail

Let’s talk about cloud! 

I mean in the web application hosting realm. Not the storage (Google Drive, Dropbox) or software as a service (Salesforce, Basecamp).

Let’s talk about a use case before and my own experience.

My former company Evocatio Solutions technologiques manage a pretty large site at the domain uda.ca.

The use-case on my recent experience

This is a complete business management web application that manages an union who represents french speaking artists in north america (mostly residents of Canada). We built a complete web application that manages many aspects an artist needs to represent themselves and be found. A big part of it is a 140 tables worth of artist description listing details as small a hair length and types of musical instruments to voice tones. It also manages renewal, communication with agencies, portfolios, and management of contracts with managers and more.

Not to forget the very heavy databases queries we generate to search, for example: <example>An asian woman with white hair playing yuku lélé who can pilot helicopter AND ride motorcycle …</example>

Yes. Database queries get very big, very quickly. Not only in the search engine I described, but through all the features.

That, to my opinion, is heavy. Also considering that that Artist’s Union has several thousand members.

This information is on top of my head, please do not take this into real numbers, I did not look the latest deployment needs.  But for the server side, it only uses a simple Virtual machine with 4Gb of RAM give or take.

That is my point about expanding hosting without optimizing stuff around.

What your web application has to consider then

Amazon and other Cloud service is about mostly about automated server deployment.

But the powerful offering of “scale tour application” with computing cubes that automatically scales requires more than just nodes.

It requires the code (here again) to support:

  • multiple databases hosts and types support (Cassandra, Solr, MySQL) specialized for the type of data to store
  • User upload files replication
  • Database/Keystore (CouchDB, Mongo)

All spanable on multiple hosts by a mere change of one configuration file.

The code itself should:

  • Be deployable by a simple phing/ant/nant task
  • Hosted on a NAS mount that you could create an other machine and use when time of computing need happens

All this (for some parts) is what is called Continuous integration (Wikipedia) some deployment strategies (also here and this blog post too), and most of the time. It’s not just the continuity and automation that matters, but the underlying deployment mechanism can be provided by third parties, like Heroku and many others.

Some steps you can look for if you feel your web application is slow

It all started by a discussion thread in a mailing list. A guy who developed a shopping cart and payment gateway using a CMS.

My first reflex, before thinking of scaling the server I thought I should give some pointers on things that can hog the site, before going to think to scaling solutions.

That was all before continuing talking on the cloud that I answered later that I answered later on that blog post.

The thread started as follows:

> (…) I have a Magento modified into a e-commerce site (…) that
> me and my client feels slow, my client has asked about Amazon hosting. They
> do everything else, CDN, the works, shouldn’t their hosting
> be superior?
> What would be worth for a test drive, I’d say, if you think
> your site’s performance issues can be addressed by
> throwing CPU, memory, storage, etc (…)

My answer

I doubt that you need bigger hosting for a e-commerce site.

Not for the “first  thing to improve performance” action point though.

Unless your site has to provide (real) HEAVY traffic. Non stop.

It is most likely something somewhere down the execution of the web application that requires to be looked at.

Performance slowing factors

Some common explanations for slow execution time could be basically due because of one or many of the following:

  1. Network latendy
  2. Process communication problem (connection, zombie process, etc)
  3. Application architecture
  4. Hardware/Software performance

Now talking about application architecture.  This one can be a real can of worms!

Some Application architecture bottlenecks

I currently seriously doubt the order here should matter. But this is the ones that pop into my mind at first.

  1. Web service/database queries/files access across network … packetloss could also be a cause
  2. Database queries processing that could require some well picked indexes
  3. Heavy queries and frequent read write or some sleep() hidden here and there to wait other result set
  4. No http/view caching
  5. No code caching/precompiled code at all (can be config, whatever that can be pre-compiled and served into basic arrays of calculated data frequently used)
  6. No memcached/keystore service
  7. No read-only data store

An analogy

So. To my opinion, if you are using a “unpack to install” web based software such as WordPress, then add plusings without testing and looking if all of them works well together.

You are likely to be trying to make a Cheetah kitten into a humanoid Android.

As in,  you can install a lot of metal patches. Doesn’t mean it will have a full AI system and be self sustainable.

That is to illustrate, what it is lie, you should look to alternatives. At least with something closer to a droid :)

Seriously enough.

My professionnal recommendation would be to work with each “application architecture buttolenecks” proposal list before “going cloud”