Semantic Data – Making Search Engine Friendly Websites

The internet grows faster and faster each day. For many, it is the main medium to connect the world. Because of much the internet grows,  we have to sift through more and more to find what we want. The way we find  information has also changed and likewise the way we create website must change. More users now rely on digital assistants (Siri, Amazon Alexa and Cortana ) to sift through the internet for them. Businesses have to evolve and have websites that are not only visually appealing but are also semantic as this article will explain. Website should now be designed to be

First, let us get some of the big words out of the way.

Semantic: Having meaning.

Semantic Data – Put simply this is data that machines (computers) can understand.

What is Structured Data?

By Google’s definition structured data is:

A standard format for providing information about a page and classifying the page content; for example, on a recipe page, what are the ingredients, the cooking time and temperature, the calories, and so on.

Although search engines like Google and Bing are getting better and better, they are not good at telling what a website is about. AI is getting better each day however it is still hard search engines to understand webpages at the moment. Furthermore, similar content may refer to entirely different things.  For example, if you created a website about “Orange”, it could refer to the color, a place, the fruit or even more things. Structured data is a standard method of specifying exactly what the website is about.

Them most widely accepted form of structured data can be is documented on It was founded by Google, Microsoft and Yandex to create, maintain and promote schema for structured data on the internet.

An example of such data for our organisation:

Why is it important for websites to be more semantic?

One reason is that the way people find information is always changing . An example of this in are price-checking websites which crawl through different websites for similar products. The data on most major e-commerce sites is semantic. The data is standard and as a result easy to compare. The important thing to note is that users did not actually go to all the sites whose prices they saw. People find a lot information on others websites in this way.

Another example is when some user digital assistants (voice or otherwise).

gif of Siri going through numerous semantic content

“Hey Siri, whow me something new”

What happens afterwards is very much like a web search. After which she will return data on nearby restaurants. Services such as Siri understand semantic data therefore they can tell users about it.




Structured Data Testing Tool – For testing Structured Data on a Website.

Additional Reading:

If you would like to dive deeper into structured data and make  use of it, here is some recommended reading material.

Introduction to Structured Data – Google Developers. – Schema Documentation and Website.

Finally, we will also be adding a couple more articles ourselves right here.




Highlights from the First WordPress Workshop

Last week, we partnered with GoDigital and The Techvillage to have a workshop on WordPress. The workshop was a 5 day crash course on WordPress Website Development.  This training was the first of a lineup of events to support the WordPress Bulawayo Community.

Highlights from the WordPress Bulawayo Training

Highlights from the WordPress Bulawayo Training


The Five Days Broken Down

Day 0 – Know your Words

Day 0 was extended for members  to complete beginners who wanted to catch up on some of the terms that were used through the course. On this day, general terms such as Hosting, Domain Name, DNS, Plugin and Theme among others were explained

Day 1 – Setting Up the Environment.

Community members participating in the class where each provided with shared hosting space on a sub-domain courtesy of The Techvillage and Neon. A walkthrough on how to install WordPress on Cpanel was the first order of the day. The last bit of the first day emphasized the need for planning before actually getting started on development.

Day 2 – Installing a theme, customizing and Creating the first Page.

With the same hosting space provisioned for in Day 1, a practical walkthrough on how to install a WordPress theme. With installation done, participants got to learn to customize their theme on the WordPress dashboard. The day ended after creating a new blank page.

Day 3 – Plugins and Widgets.

Day 3 started off right where Day 2 had ended. Members where taught how to make use of plugins and widgets to populate their very first pages. Using Day 1’s , members added structure to the homepage of their hypothetical businesses’ websites.

Day 4 – Creating More Pages and Navigations.

Using knowledge that they gained from creating the first page, members where challenged to create additional pages for their hypothetical businesses/organization. The follow-one was a lesson on how to add pages to a navigation bar.

Day 5 – Preparing for a Real World Project.

Day Five was project preparation. The challenge was for participants to select a school of their choice and develop a website for them. Project Planning was discuss as well as how to gather content before starting development.

Follow on Events?

Due to requests from particiapants, there will be follow-on events, one will be a general guide for someone looking to start a Web Development Business.
The Second will be The Devshop‘s crash course on HTML, CSS and JS as we get ready for the more code-demanding sessions.

If you missed out on this training but would like to catch up on upcoming ones do follow us on Social Media to keep up to date

Supporting WordPress Bulawayo Meetups

We are excited to be joining a growing WordPress Bulawayo Meetups community. Meetups are an opportunity for people who love and value WordPress to get together to learn from, and connect with each other. Regardless of whether you want to learn about WordPress or meet others who work with it, Meetup events are a way to build a strong community.

Our primary goal is to build a strong software development community. Consequently, it is to address the skills gap in Software development in Bulawayo.  In the long term we hope to see our work we result in a better software environment in the country. Bulawayo Meetups give us a platform to do this and to work with organisations that share the same vision like Zimcode, The Techvillage, GoDigital and Neon

The meetups affords an opportunity for people of all technical levels to discuss WordPress related issues.  Everything from blogging to more technical issues such as developing Plugins.

We are particularly excited about  do_action events.  The Community will be using WordPress to uplift Bulawayo’s charitable organisations using some of the knowledge and conversations we will have at these meetups.

do_action hackathons are community-organised events that are focussed on using WordPress to give deserving charitable organisations their own online presence. Each do_action event includes participants from the local community coming together to plan and build brand new websites for a number of local organisations in one day.

Especially relevant to us is hosting WordPress Hackathons in the near future and interacting with Bulawayo Developers. We look forward to meeting more Bulawayo developers at such events.

Join the WordPress Community.

Community members may host their own events with the assistance of other individuals and organisations in the community. Every thing from a Blogger’s meetup to a do_action event. Reach out to the Techvillage if you would like to host your own event.

If you would like news and updates meetups you can follow the TechVillage on social media. In addition, we will also be sharing regular updates on events on our social media pages.

Join in! We look forward to having you.


A Software Developer’s Guide to Billing

One of the challenges we faced when starting the Devshop was figuring out how to bill clients for work. If you remember from our story on how we began, we were mostly a group of developers who had no previous knowledge of developing commercially. Naturally, we lacked background in the commercial aspects.

A few years on, we have certainly learnt a lot about how to approach it. Different clients will require different billing methods but here are a few we have used over time.

Working with clients who bring a lot of changes has it's complications

Most local developers use a fixed cost development model. It is great for the client but at times not so much for the developer

Some Billing Methods


This is the most common kind of billing with local developers from our experience. This method of billing involves initially assessing the amount of work to be done. The client is then billed a fixed cost for the entire project.


  • Clients tend to prefer this method of billing. It makes them able to plan ahead by knowing how much to set aside for the work.
  • If you are a very skilled Developer you can finish projects that may take longer for other developers and consequently get more out of your time.


  • When dealing with “sticky clients” whose changes constantly evolving you will spend a lot of time on a single project which results in you getting less out of your time.
  • Work done must be well understood prior to engagement or it may be undercharged.

As a general guideline for developers choosing to take this approach, it is good practice to create a specification sheet or a Software Requirements Specification before billing. In addition to helping you to be able to understand the amount of work, it will also help you in planning the project.

The Expectation and Reality of a Software can be reduced through proper documentation

It is important for the client to understand what it is that they are paying for. Software Requirement Specifications prevent an endless loop of changes caused by the difference between their expectation and what the developer got from their descriptions



Featured based billing (may be referred to as Functionality based) is in many ways like Project-based billing except instead of the whole project, you bill per feature. It has some added advantages over the Project-based approach.


  • The method works best for projects with incremental release cycles. If you are adding functionality on an existing project that may have been built by someone else this method would work.
  • The nature of the feature-based approach does not give much room for misunderstanding requirements which reduces ‘sticky clients’.
  • Work is easier to measure for a feature than for an entire project.


  • Billing paperwork is more frequent so time doing paperwork increases.
  • Mostly works on bigger projects (Cannot really break down a website into features, can we?).

Apart from the overhead of additional paperwork, this is a generally a good method to adopt. It eliminates some of the problems with Project-based billing


Hourly billing is a great way to cost projects. This method typically involves recording the hours spent on a project and the sending an invoice based on that.


  • Works for clients whose requirements are vague.
  • Addition of requirement by the client does not cost the developer.


  • Different skill levels of developers may need to have different hourly rates. More seasoned developers would generally  finish work fast so would have a higher hourly rate. There is no sure way to calculate such a value.

Generally hourly billing has a lot to offer for developers. It gives the client reasons to be more succinct in their requirements. Work moves through the pipeline faster. It does require for the client to have some assurance that you are making use of their hours efficiently.


A beatiful benefit of hourly billing. Shut up and take my mney

A key benefit of Hourly billing is that the client will pay for any hours caused by additional requirements



Daily and Other Time-based Methods.

Time-based methods generally share the same advantages as hourly-rates. The key difference is, as the time-period becomes longer there is increased need for accountability. For example a client on a daily billing schedule may want to is you are spending the entire working day writing code.



In conclusion….

There are multiple ways to approach. The truth is there is no one perfect way to approach it.  There are projects that will require a mix of two approaches (Hybrid Billing Models). While this is not a very specific guide to billing, we hope it will help you get started.





DevOps at the Devshop

The biggest lessons we have learnt as a startup are in business operations. Some context: our team consists entirely of developers. It has been that way from the beginning. We have always been more comfortable designing algorithms and user interfaces. We have not enjoyed the same flair with the business end of operations. Us evolving into a growing and thriving business meant we had to make ourselves more productive. We had to find ways to optimise our profitability without compromising the value that our clients and partners have grown accustomed to. This meant gap closing between the development and the business operations of the Devshop. This became the starting point  of redesigning our DevOps culture.

What is DevOps

Donovan Brown, Principal Program Manager at Microsoft defines DevOps as

“The union of people, processes, and product to enable continuous delivery of value to the users”

To increase the value that we offered to our partners and clients meant that we had ship code faster. We had to do this while delivering the same kind of work that had made them choose us. Achieving this meant engineering and operation concerns had to work together much more seamless. This is through client on-boarding, planning, development, testing, deployment and maintenance phases of our process.

Using the right tools

An undoubtable aid to our DevOps culture is Visual Studio Team Services. By adopting VSTS we got features like Source Control Management, Private Repositories, Planning and Workflow Management tools like Kanban boards, Tools for Continuous Integration and Continuous Delivery. Visual Studio Team Service gave us an end to end solution for all our technical devops needs. The beauty of Visual Studio Team Services was that is allowed us to automate most of the mundane task of our process and let members across our team do the less mundane tasks. The VSTS platform allows us to use any other framework for any other part of the process if we feel we need to.

We also adopted Microsoft Azure as our platform of choices for web service for a number of reasons. One of these reasons is how seamlessly Azure will integrate with Visual Studio Team Services. This made a lot of the processes we implement available through very easy processes.

Automation- what a beautiful thing

One of the sweet benefits of adopting this new DevOps culture was the number of things that we have automated.


A single “git push” command from our code editors now sets in motion a beautiful process for a number of our projects. A case of a Webapp with a ReactJS frontend and a NodeJS backend – a single push triggers the following process.

  1. Uploads Code to a private team repository
  2. Upload then triggers a Continuous Integration Process.
    1. The CI Process starts a remote hosted machine.
    2. The code in the repository is moved to that machine.
    3. A Powershell Script triggers “npm run build” command on the remote hosted machine.
    4. Process creates React /build deployment-ready folder.
  3. Once the process on the hosted machine is complete is triggers an Azure Web Deployment.
  4. The /build folder is moved to Azure.
  5. After completion an email is sent notifying whoever triggered the build on whether it has been successful.

The beauty of this process is that it is flexible to my technology stack and the DevOps culture we choose to adopt. We can choose to run tests at the end of the process. We could write scripts to have the code pushed to the live site if it passes a set of tests.

Added value for clients

The level of automation in our process has now allowed us to serve our clients better. We now have backups for every project we take on for our clients. As a result we can redeploy their work for them with the push of a button. Also noteworthy, small changes are made and the deployment process triggered by a single “git push” command. Due to the automation, a large cost overhead is avoided. Our development process has improved significantly because clients can see our internal project communication while we work on their project. Clients are even able to see live versions of the work as it progresses. We now provide telemetry for our clients so that they know when to revert to a previous deployment according to response by users.

Added value for Users

For applications like Dialogue and Foodie, we can now address bugs more promptly and ship new features much faster. Because we collect telemetric data with every deployment, we are able to see our user’s response to every deployment. This allows us to continuously and consistently deliver more value to end-users

Added value for developers.

While running a task like “npm run build” is simple, it runs for a few seconds which may take a developer out of the zone. Our new adopted process allows all this to happen on an external machine. Our previous process of deployment process for example, required for a developer to zip a file, login in to our hosting platform, navigate to the correct folder, upload then unzip the folder. This needed to happen whenever we wanted to update clients on changes we have made. This has greatly improved productivity.

DevOps has greatly improved the efficiency of developers

DevOps has greatly improved the efficiency of developers


This article could never exhaust the benefits we have had at the Devshop after adopting our new DevOps culture. The adoption has increased our productivity on monumental levels and we will be sharing more articles on the technical and non-technical aspects. Overall, we have managed to make developer more productive resulting in greater client satisfaction and consequently healthier profits. We recommend that organisation take their DevOps seriously. While we have achieved much from the time we to the decision to adopt devops, it is is a continuous  process and we are always looking for ways to make ourselves better

Building a Community

The last two months have been a learning process for us. We deployed Dialogue to the public. Dialogue is huge for us because becomes the first complete platform that we have worked on to this extent. The process, subsequent product and adoption had a lot of lessons with regards to our work culture and our operations. Adapting to lessons such as these ones is an essential part of how we keep ourselves relevant as a business. The Devshop has always been about enabling software developers to be able to deliver meaningful software. We will now be building a software developer community with greater intensity. This community will enable us to better share what we are continuously learning and reach even more developers. We have already learnt fundamental lessons and will be sharing then through the community.  Technology is the application of scientific knowledge for practical purposes. Advanced software is not more important than simple software can make a meaningful difference for an ordinary user. We will be focusing more on implementing simple software that can affect lives in a meaningful way. This definition has allowed us to reflect on the software that we will  be building. One of the functions of the community is to facilitate discussion. Discussion such as how we can design software that can make real impact in our community. These lessons require a shift in work culture for us and for many developers we interact with. It is the nature of developers to enjoy a good challenge. They have an affinity for mentally-stimulating projects.  There is a temptation to learn a framework with every project. It is important to find the balance between learning and using what you are already know. Our drive will now instead be about how many lives we impact through our software.  

Putting in Action through Community

We will be reinforcing our efforts to build this community by hosting a series of developer meetups. We will share the challenges and triumphs of building a software based business in Zimbabwe and encouraging as many in our community to do the same. Equipping developers with the skills they need to develop useful and meaningful software is one of the foremost reasons for our formation. A mandate we imposed on ourselves.  With this community we anticipate that the effects of the work we have already been doing will be more widespread and reach an even larger community of developers. We have no doubt about the possibilities that local developers can open for local communities and we are excited to get started. We will be releasing the dates for our first community meetup in the coming weeks. Lastly, we are always excited to receive feedback from the public, it helps us deliver better and better projects. If you have any suggestions do not hesitate to get in touch with us.   Devshop Community Hackathon

Introducing Dialogue

For a long time at the Devshop we have been playing and experimenting with ideas on how to get people to share more and engage more in conversation. We have attended a number of events where we have explored concepts. The results of the exploration and experimentation have been Dialogue.

Dialogue is a platform that curates posts from social media with a chosen hashtag allowing the user’s audience to interact in a dynamic and interactive way. This version of Dialogue ships with the following features among others:


  • Profanity Filtering.
  • Multiple customisation options.
  • Easy to use Dashboard.
  • Relive feature which allows users to enjoy the entire experience again even after their event has ended.
  • Instagram and Twitter Support.
  • Emoji Support.
  • Ability to make Live announcements from the Dashboard.

The Dialogue Dashboard

The dashboard is control panel from which users can gain control of their account and what their audience sees when they go live. Some of the features that a users can control from the dashboard are:

  • Colors of backgrounds & picture borders.
  • Change duration between transitions.
  • Specify the hashtag(s) you would like to follow.
  • Send out announcements to your audience.
  • Take control of your account and top-up credit.

The Dialogue Interface

The interface is the part of the web-app that your audience will actually to see. This interface will have a URL once you go live that will be able to be shared with any other device that has a compatible browser. The interface displays twitter and instagram posts including posts with up to 4 images. Announcement made from the dashboard will also be available on the same interface.

Even more control of what your users see

We realise the sensitivity that may come with some events. Events may require that you filter out content which is not suitable for family events. Further to features we are actively building the ability to filter out obscene content that may contain nudity and foul language. In addition to filtering out that content we are also building sentiment analysis into the application which allows you to control the emotion that you want to put the most focus on. This allows Dialogue to be suitable for  any kind of event without having to worry about spam posts.


In addition…..

Memories are invaluable. You always want to look back at good times and smile, sad times and remember how you moved on from them. In this version of Dialogue we wanted to allow users the ability to store their memories. It will store every post as it happens and allow you to Relive the entire experience exactly as it happened during the time you followed the hashtag. You will be able to share the entire experience with anyone else.


Get Started

Share More. Engage More.  Available for public use on the 25th of September 2017 on





Our Story : How the Devshop started

Our story starts in a room in the basement, where a group of young people sought to start businesses that would change the country and eventually with the right determination, the continent. A community of young and vibrant young people who have ideas that they feel will disrupt the way local business conduct their everyday processes.

From the earliest days, the lack of skill in our small community to develop world class software became more and more obvious. Ideas requiring technical knowledge far outweighed the developers who could build them. Technology was an essential part of our delivering some of the small ideas that would impact our communities in a huge way.

The Techfest Hackathon

The Techfest Hackathon

In that small community a developer community formed and using our individual strength we began to upskill each other and continually and consistently became better. We learnt that there was strength in numbers that our combined efforts to better ourselves was greater that the sum of our individual effort. From then we have never looked back and continue in our mission to equip and empower as many developers as possible to contribute to their teams and to start then grow meaningful business.

Over time, one belief has become a fundamental to the way we work: We are only as good as how much we learn and how we implement what we know to solve problem and solve challenges that the people around us encounter everyday. We realise that we only become valuable in our societies if we have the audacity to learn and build.

Moving into our new home

The Devshop was founded to close the gap that was opened between local technology and global technology. The need was realised when each time local entrepreneurs with little or no technical knowledge required software in one form or another to take their businesses and startups to the next level. The need for more developers became apparent and the very first Devshop community was formed to address this need.
Our journey so far has been a never-ending lesson. To be an agent for change we realized that we could not be traditional in our approach to work and must consistently be ready to learn new thing so that we do not open the very gap that prompted us to start
Our most recent lesson was that we need a place to call home where all ideas can grow, a place where developers on the Devshop team can meet, build, conduct work and continue to offer value to all our end-users. In continued pursuit of vision to offer great services we have found our first home in central business district of Bulawayo
We are not perfect but perfection is something that we pursue every single day we exist.
To our partners, our customers and to the public. We look forward to building thing in our new home that can take everyone further.
Here is our new home. We like to call it ‘The War Room’