HOME | BACK
Background Image
Common
Controls
Resource


Next Arrow

Before Next Arrow

The Common Control Resource was designed to replace Functional Requirements Document (FRD)—old, lengthy Word documents that held the requirements and process flows buried with a bunch of other data and information—useless to most prospective users. It took a lot of hard, manual searching and sifting to find what most users would need in this document. Particularly obtuse to new employees. One example, the FRD for "grids" was 41-pages long, much of which contained striked-out information, and the requirements for three types of grids. Hard to compare the differences.



My original thoughts on this came from when I was onboarding. When I asked where to find "X," I was told go to "Xx" look up "x," then go to "XXxx" sift through until you find "xxx." This will lead you to "XXX." Take that, go to "XxX" and there you find "X." Whew! Who uses this thing? Apparently nobody.

So what I did is first examine these FRD documents to determine what is in them, what is of value, and who would benefit from this data. Well, the requirements for all the controls we use, Microsoft, Telerik, and custom are all buried in there. It was very, very easy to miss what you may be looking for. So upon examining these documents I segmented the data into several logical groupings: Summary with a sample picture, Process Flow with diagram, Requirements with links to specific subcategories, UX/UI notes with coding samples, and Dev Resources with links to references and demos.

My first inclination was to create and mock this up in HTML, and that's what I did to pitch the idea. The idea initially got shot down as there was, "Other plans in the works," but soon after I was asked to take this on, but I needed to do in Microsoft Sharepoint.




After Next Arrow


Determining who the users would be was rather simple—anyone who dealt with the controls of these applications would be a target. Solution analysts, developers, quality assurance testers, UI designers and user experience designers would all benefit. Especially beneficial to new employees.

Though Sharepoint isn't ideal to manipulate the HTML, it was doable, and all the FRDs got converted. This was hosted on the Solution Analysts Sharepoint Server accessible to anyone on the network. The documents were broke down into the subcategories as stated above. An alphabetical index listing makes finding the control one seeks very quick and easy to find, clicking the link takes the user to the Summary / Mockup screen showcasing a sample picture and summary explanation.

Some controls have multiple variations and each is a click away to jump laterally across the different versions. The Grid controls is such an example with seven versions. Clicking from TC-GRD-001 to TC-GRD-006 will take you from the subcategory you are on to the same subcategory to which you are going. That is, if you are on Requirements on one version and click on the link to another version the user will land on the Requirements screen of the targeted version (not the initial, beginning Summary screen). Likewise clicking on TC-GRD-001 link from the Dev Resources section of TC-GRD-006 will take you to the Dev Resources section back on TC-GRD-001. This makes it very easy to compare the difference between the two, rather than back and forward navigating. References to other controls within the context are direct links to the cited control to easily and quickly reference it.



The Conclusion

The reception to this resource has been very good. I see developers reference it, solution analysts use it, as well as QA and UAT. It's offered as a reference for onboarding, and I have been told it's been very useful and is used often. I use it often!

This has also led to future plans for a similar resource for Thomson Innovation controls. In like manner, my UI coworker and I have been tasked with creating a UI Standards & Guidelines resource for QA and UAT to use as a reference when doing their testing. The purpose is for QA and UAT to understand overall requirements and guidelines when testing, to spot things that may be amiss outside their direct test requirements, and then to let someone know. This has made an immediate impact, with QA immediately pointing out issues they would have otherwise glazed over.