The Bare Minimum

The first iteration of the Google Search Engine, credit:

All web services and products have to start somewhere. Even Google, the ubiquitous search tool, started as a text-only web indexing tool with minimal (but then advanced) functionality. In that same vein, our journey has reached the point of releasing what is known in the industry as a minimum viable product (MVP), the first of what is hopefully many successful iterations of our product. To that end, our MVP has limited functionality, only the base requirements are met, and there is still a lot of room to expand and grow on the concept.

The splash page for the ID Card portal, displaying the ID and essential contact information

Our concept is very simple, in the sense that we have split the web application into two essential views: the client (those with ID cards) and the manager (those who manage the ID cards). The client view, shown above, addresses all of the current concerns for ID card-holders, namely viewing the ID card itself and related information, seeing the areas to which they have access, and a form to create an access request for an area they do not have access to.

The My Areas view, showing the buildings a person has access to

The “My Areas” view currently showcases where a user has access to, where clicking on the building itself will list related information for that building (which doors they can open, etc). In future iterations, this section will show every campus service a user has access to, including web applications (and associated privileges with those applications).

The Request Access form, which sends a ticket to the ID card managers

Finally, the user can submit an access request for an area on campus, specifying all necessary fields for the request. This request then gets forwarded to the requisite manager who has the ability to approve or reject this request. Future iterations will allow the user to see the status of their requests (approved/not approved) and any possible reasons why the request was not approved.

The manager view is a little more complicated, simply because negotiating an access request system with multiple types of access and locations involved a lot of moving parts. To that end, we believe we’ve created an elegant and integrated approach to the manager view.

The manager splash page, showing updates on requests/buildings

The manager view, shown above, has a more “console-like” view to it, in line with the needs of a manager. The view is more action-focused, as opposed to the digest-focus of the ID card view. Thus, most of the side navigation bar items are action-based, where “Pending Requests”, “Create ID”, and “Create Building” all necessitate future action. The views above also illustrate the need for different levels of managers, ie a building manager should not be able to create more buildings, that should be relegated to a campus manager, and the same with creating ID cards.

The pending requests manager view

However, all managers will be in charge of some type of pending request: building managers receive access requests for their buildings, and campus managers receive all requests (including those for new/edited ID cards). The requests are detailed here with the basic information, namely who is submitting them. Clicking on each request will in the future reveal the type of request and anything actionable.

Future iterations of the product will expand on functionality in essentially every area of this concept. Our push to production will take place this week, at which point we will detail all of the functionality in a demo, either through a slideshow or video.

Warning: technical discussion below

Pitfalls for this week faced by our engineering team included mostly getting started and forming the team dynamic. A lot of the tools that we’re using necessitate up-to-date programs and modules, and every member of the team had a different setup. Likewise, configuring the tools themselves took time to climb the learning curve. Our team members were familiar with AngularJS, but had to make the transition to Angular (aka Angular 2). We also had to pick up new frameworks like Django and setup a PostgreSQL database. However, once the learning curve was climbed, many of the pieces fell into place, and we are still ramping up development. Our critical areas of improvement involve mostly further developing our schemas to accommodate all of the feedback we’ve received from the MVP, and also fine-tuning our knowledge of the new frameworks and adding functionality. We’d like to thank those who provided valuable feedback for this round, mostly to Ming Chow for his expertise in the field.

Show your support

Clapping shows how much you appreciated Caerus Karu’s story.