Components of CrowdstaffingThe Enterprise Web App
For one leading recruitment companies of Silicon Valley, developing a web app with better standards and quality was a must. And this is where Zenith Talent approached Cyphertree and gave the responsibility of building a robust Front end of their app.
Crowdstaffing is a curated marketplace where enterprises, MSPs and certified recruiters are brought together on single platform to hire amazing local talent. The nature of this app is very process and workflow oriented.
We learned quite early that in order to keep the business going and not letting any maintenance issue come in between building new features we have to come up with a better architecture where re-usability and design patterns have be given top most priority. We addressed following big issues to tackle the vastness of this product:
- Efficient way of Data entry:
There were a lot of entities and each entity had a huge data schema. We didn’t want to confuse the user with big forms to fill. We needed to break down these forms and make them reusable.
- Roles and permissions:
There were more than 100 sets of rules and permissions for more then 10 types on users on the system. The visibility of different elements and functionality was based these roles and permissions
- Offline to online process:The processes were run offline for most of the recruitment, hence we needed to make this whole process online with a proper workflow. This was one of the toughest challenges since it had a lot scenarios and conditions. Moreover users were not completely ready for a abrupt transition.
With a big challenge ahead, we knew that a fresh approach of building componentized and modular applications is the way to go forward. Taking a cue from Unix Philosophy we started thinking about the clean modular architecture for Crowdstaffing web app.
The very first thing before starting any project at Cyhertree is
configuration. Meaning, a proper setup of the project, which contains a proper build process, automated deployments, version management, test-cases setup, machine setup, probably dockerize as well etc. Because we don’t want to bother ourselves with these one time tasks at the time of going beta. It is always a good practice to have your project configured prior to start of development. And try to automate things as much as possible because you want your team to focus on the implementation of the project.
We chose AngularJS as our front end framework for building this enterprise application. Our extensive experience with the framework since 2013 and looking at the stability so far, we were sure AngularJS’ opinionated architecture will provide us a better performance and ease in developing scalable components.
Before jumping directly to PSDs and requirements we started analysing them in terms of UI and started taking out patterns out of them. This helped us in mapping a set of basic components such as listing, pagination, messages and in-app notifications, common components for handling file uploads, maps apis etc. that are going to be used in both the apps. Once these components are ready we jump into business requirements and making modules in various apps. Its like building something out of lego pieces, here components act like set of lego pieces which are waiting to be joined together. This way we spend less time in building features as per business logic and we can also eventually change them as per requirements. Hence a proper care is taken by lead developers before merging the code to make sure we are not polluting common components with any app specific business logic or data. Separation of concern is very important for enterprise apps which are to be maintained for a long time.
So from a very technical POV, the question is what did we achieve by setting such conventions and configurations:
- Clean Foundation
Clean, maintainable and scalable code using tiny solid modules. Hence less confusion among dev team in implementing new modules/features or modifying existing modules/features, without disrupting any other module in the application.
- Test Driven Development
Test case setup, right from the beginning. So with every module you also write test cases.
- Speed and Performance
Blazing fast website due to gzip compression and s3 CDN settings.
- Estimated Deliverables
Easy to estimates tasks and an exponential growth in development. At first the reusable components will take some time to get developed but this delay comes with a huge benefit in future where implementing various features will be done in minutes.
For the end users,
- Simple and straight-forward UI
The UI of th application did change multiple times, with constant feedbacks from beta users we kept optmising our UI, even completely changed the look and feel at one point. We were able to accommodate such changes only because of solid modular architecture.
- Clear Workflow Implementation
The transition was smooth, this was only possible because of constant iterations and improvements in the workflow by user feedback. We gave users preferences to choose between UI layouts they are comfortable with. For e.g. listing pages contained a tabular as well as a card view. This enabled user to either choose “Bulk records view” or “Bulk information view”.
- User engagement
We added a lot of help text and in app notifications which kept users engaged and informed about whats happening in the system.