Welcome to our second installment of our Best Practices for Argos DataBlock Design series. If you were following along with our last post, you should now have everything you need to get started with the visual design of your DataBlock. There are a few aspects of the design you should consider carefully, to make sure that your design scheme is working to make your DataBlocks friendly to your users.
Planning Your Form Layout
While the designer has freedom to lay out the DataBlock form however they like, it best to have an idea of how it should be laid out before digging into the formal design work. Having a plan of attack beforehand can speed up the process greatly and reduce the need to go back and move objects around. While your end users may not have a clear picture in their head, they will definitely have opinions on what does and does not make sense to them when it comes to the layout of your forms. Work with your end users and sketch out a form layout. Communication is the key! The medium you make your layout in isn’t as important as the process itself. Anything from using pencil and paper, to a simple paint program sample, or even a mockup using a tool like Balsamiq can make your design choices much easier to make.
It may sound like common sense, but I cannot stress enough how far consistent design can go to keeping your DataBlocks easy to use and understandable for your end users. It is always best to use what is familiar so that your end users don’t get lost.
For example, let’s say your users want an ‘All’ option for the items they can select in a list box. You have numerous options: you can incorporate a union query to manually create an ‘All’ selectable option, or you could create a check box that toggles the list box to only return an ‘All’ selection. You can do something similar with a radio button, or a drop down box. Once you have decided on what design suits you or your end users, stick to it. Do not confuse your users by mixing up the way they can select their parameters. If you opt to use a checkbox, use the checkbox method on all your forms and dashboards when applicable.
Similarly, using the same institution colors, the same fonts and layouts, as well as objects across your DataBlocks gives end users a sense of uniformity. Having a polished uniform look to all your DataBlocks unifies Argos for your end users. You make Argos approachable. You make Argos a single application, rather than have each DataBlock look and feel like a completely different program. Your DataBlocks become your institution’s DataBlocks. Designing your DataBlocks to mimic your institution’s website, for example, allows your users to relate to Argos better. For end users familiarity goes a very long way to help them understand and use your DataBlocks.
Use the Library of Objects
One of the best ways to keep your designs consistent (and save yourself a lot of development time) is to use the Library of Objects. Most form objects can be stored in the Library of Objects. Not only are the object’s basic properties maintained, but also any SQL or selections created for them. Instead of writing the SQL for a list box to select term codes repeatedly, you can save the term selection list box into the Library of Objects. You and other developers at your institution can build off of one another’s work to create a robust Library of Objects.
For example, save your institutions logo image as an object so you and other designers don’t have to look around for the image file every time they need it. More than one object can also be stored at a time. Have you ever created a FOAPAL selection that relies on one selection to build the next? It’s possible to store the whole group of selections into the library as a single entry. That way they can be retrieved at once and work together from the start.
As mentioned earlier, your institution may want to use templates. By storing multiple objects in the Library of Objects at once, you can create a template for future dashboards. Do you have a common header all your DataBlocks should use? Store the header, institution logo, panels and anything else that will always be used together as a single object. From the start of your next project, that template will be available for you to skip all that initial preparation work.
Now that you’ve got a good grounding in keeping your designs clear and consistent, you should be all set to start building out the interface for your DataBlock. In our next installment, we’ll wrap up by talking about the value that good documentation can add to your DataBlock designs.
What other design habits do you use to keep your DataBlocks looking tidy and intuitive? Let us know, in the comments below!