Best Practices for DataBlock Design, Part Two: Getting the Look Just Right

12/02/2014

Comments

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.

Be Consistent

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.

Like this blog?

Here’s another one you might want to check out:

Related Posts

Evisions CO-OP: Top 10 Most Viewed Argos DataBlocks

Evisions CO-OP: Top 10 Most Viewed Argos DataBlocks

The Evisions CO-OP User Community is a collaborative place where clients can share ideas, experiences, development, forms, DataBlocks, and reports with their peers. To give you an idea of what fellow Argos users are doing and looking at, we present the Top 10 Most...

Navigating the Evisions Customer Community

Navigating the Evisions Customer Community

The Evisions Customer Community has always been an invaluable tool for clients. It serves as a resource for peers in higher ed to share knowledge and find answers. On May 7, 2019, a new community portal was launched. Why? Because we listened when our clients told us...

Shining the Light on SQL Variables in Argos

Shining the Light on SQL Variables in Argos

When an institution begins its reporting efforts – let’s say after recently changing databases or reporting tools – one of the first steps usually taken is to replicate what they had before. Often, this means creating some type of file and distributing it to users....

0 Comments

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Share This
X