General IITS User Services Support
General IITS User Services Support
Monday through Friday, 8 a.m. - 5 p.m.
(315) 792-3115
Banner and Administrative Application Services
Information and Application Services is responsible for the college wide web development, portal technologies, SCT/Banner Programming, testing, documenting, and maintaining computer programs and information files for various University departments. We participate in evaluating products that may enhance University computing needs as relates to all technology.
Information and Application Services Provided
- Manage web server and website.
- Manage Faculty/Staff web server and sites.
- Provide assistance to Web Coordinators in editing, updating, and creating the web sites for their areas.
- Provide assistance to faculty and staff who seek to develop their own web pages.
- Develop new pages.
- Develop underlying code to handle forms on the web.
- Programming for the SCT/Banner system.
Banner 9
Application Navigator is used to navigate the Banner 9 suite, including Banner Administrative Pages and new Self-Service Banner applications.
Banner Web
The current version of Banner Web will be phased out as we transition to Banner 9.
Banner Documentation & Resources
Banner 9 - Keyboard Shortcuts (PDF)
Banner 9 - Getting Started (PDF)
Banner 9 - Getting Started (Video)
Banner Web for Faculty (PDF) - Login Required
Banner Web for Development Officers (PDF) - Login Required
Banner Navigation Guide(for Faculty & Staff only)
Argos
Argos is our new enterprise reporting solution. Argos can meets reporting needs from simple ad-hoc queries to advanced dashboards with interactive charts and data cubes. The report builder/viewer allows both technical and non-technical users to create and run reports on-demand and view results in a graphical user environment.
It offers dashboards, OLAP cubes, graphs, charts, and scheduling and delivery options. Argos will gradually be implemented campus-wide and will be a collaborative effort between functional area experts and IITS.
Utilize the links below to access Argos as well as Argos documentation, training material, forms, FAQs, and procedural information.
Below is a series of options for accessing training material for using Argos. Traditional training guides that can be downloaded in pdf format. Pre-recorded Evisions created sessions can obtain by clicking on a link and downloading a file locally which then allow you to view their training videos. Evisions also delivers live Report Writer and Report Viewer training on a bi-weekly basis. We will also be conducting our own locally delivered training on Report Writer, Report Viewer, OLAP Cubes.
Select Form(s) to Download
Need to request an Argos account or complete an Argos DataBlock request submission? Select the appropriate form from the links below, complete the form, save and email to the argos@utica.edu
Argos Training Guides
These guides are Evisions created user guides in pdf format for the products and different user roles.
Argos Report Viewer User Guide
The Argos Report Viewer User guide is intended for the more casual users who are able to run reports and save and distribute the output in a variety of useful formats.
Argos Report Writer User Guide
The Argos Report Writer User Guide is intended for intermediate users who will use IITS developed Datablocks to build a variety of csv, extract, and banded reports.
Evisions Pre-recorded Training Videos
The pre-recorded training videos are a great way to jump start your use of Argos as a Report Viewer or Report Writer. Locally developed training sessions will be developed that will supplement these rather than replace them so users are encouraged to view them.
Upcoming Evisions Delivered Live Online Training
You will be required to create an account on their Evisions website to register for this training.
Every couple of weeks Evisions runs live training sessions for new users or users than need a refresher in the products. You have to log in and attend the live session but it comes with the support we pay so you are encouraged to use these sessions also.
- Argos Report Viewer (Click to Register) - 12/16, 1/6, 1/20
- Argos Report Writer (Click to Register)- 12/17, 1/7, 1/21
UC Training Sessions
Argos User Start-Up Procedures
*Note: More detailed information about accessing the various training options is available in the Argos Training and Documentation tab above.
- Request an Argos Account using the Argos Account Request Form.
- Attend a Report Writer training session. You have multiple options and they are described on the Training and Documentation page
- Attend an on-site DataBlock Discovery Session where you will meet with IITS Programmer Analysts to help define the requirements of datablocks.
- Request a DataBlock be built for you using the Argos DataBlock Request Form
Q. How to I gain Access to Argos?
A. You must first complete an account request form via this Forms, Links, and Resources section of this Argos site.
Q. What roles can a user have within Argos?
A. Argos has three pre-defined roles: Report Viewer, Report Writer, DataBlock Designer. Nearly all faculty and staff can have Report Viewer access. Individual's within different departments will be designated as Report Writer by their supervisor and they will receive additional training beyond the Report Viewer. Datablock designer roles will be limited to individuals within IITS.
Q. Why can't I just have access to the data in Banner and do with it what I need?
A. The Banner database is primarily a transaction-based system with literally thousands of database tables. It is not optimized for reporting. Experience has shown us that handing a person access to those raw tables generally results in the production of inaccurate results.
Q. What is a Datablock within Argos?
A. A Datablock is basically a made-up terms used within Argos to represent a SQL-based query of multiple database tables. It can incorporate custom functions, multiple types of table joins and set operations to result the desired results.
Q. What training is available for a Report Viewer?
A. For those with the role of Report Viewer, there are multiple options. You can view the pre-recorded Evisions-produced Report Writer video available from within our Training and Documentation section. Every other week, Evisions runs live remote training sessions. You can access those through the same pages within our site. We will also conduct in-house sessions to supplement material not covered in the pre-recorded sessions. Users are encouraged to view the pre-recorded sessions as they are quite good.
Q. What is an Argos Dashboard?
A. All DataBlocks have at least one dashboard which is created along with the DataBlock. The dashboard is used to gather any input parameters that are needed when you run a report. Dashboards can also display results on the screen, if the DataBlock designer configured it to do so. A single Dashboard can contain multiple forms with information.
Q. Does a Dashboard have to be associated with reports?
A. No, a dashboard can exists without any reports having been created. There are times when a Dashboard is sufficient to have without the need for report. They can be a good choice when you need to access information quickly, but do not need to save results as you might when running a report. You can think of a Dashboard without associated reports as similar to a Banner Form except we have the ability to customize these more easily.
Argos Resources
Learn about DataBlocks and the design process.
With Argos, any task a user performs is based upon a DataBlock. Any form, any dashboard, and any report you run will be done within the scope of a particular DataBlock.
So, what is a DataBlock, really?
A block can be a lot of things. DataBlocks can contain an abundance of information or none at all. They can include a complex array of forms, objects, and or they can consist of a single, simple query to return one specific data set.
The easiest way to understand the role of a DataBlock is as a container. Every time an Argos user creates a new DataBlock, they’re essentially creating a new, empty box. By adding objects—which are used to define the data returned to the DataBlock—users “fill” the box by displaying data from their institution’s databases or data warehouses. Users can also design forms that include elements like charts, OLAP cubes and multi-column lists to display the data. They can also generate reports based on the data returned, which can be printed, distributed, and exported. Since every institution has a variety of departments, each with different reporting requirements, DataBlocks can be used to present relevant data in a way that suits a particular department’s needs.
Guide to key DataBlock elements
When designing a DataBlock—the form design is used to create individual “pages” for the DataBlock, and the report query contains the SQL query that allows end users to generate reports using the data returned. Report writers can design one or more reports. The dashboard allows users easy access to all forms and reports. These four elements make up the anatomy of your average DataBlock.
Below is a little more detail on the role of each element:
Dashboard
The dashboard is the control panel for the DataBlock, providing end users with a visual interface to all the pieces of a DataBlock. Uses can constrain and interact with the data being returned. Dashboards are made up of all of the forms, reports, control objects, graphics, OLAP cubes, and any other visual elements the DataBlock designer wants the end user to see. Dashboards also include controls that allow users to save their variable selections for future use.
Report Query
The report query is the part of the DataBlock which contains the SQL statement to return the desired data. Typically, the SQL refers to objects on the forms to gather input from the end users. While not every DataBlock requires a report query, if the end user wants to produce any kind of report, the DataBlock must have a report query. Although DataBlocks can include many reports, they will only have one report query.
Forms
Forms make up the individual “pages” of the DataBlock’s dashboard. Forms typically include variables, which collect input from the end user. When an end user chooses a value for a particular variable, it constrains the data returned. Forms can also contain visual elements to display Charts, OLAP cubes, data lists, graphics, and other visual elements can be added to forms to visually represent the data, making it much easier for the end user to interpret.
Reports Generated using the data returned by the report query, reports are the final product of the DataBlock. They can be used to present the data outside of Argos—on paper or in a file. Banded reports allow end users to design formatted reports with groupings and subtotals. Users can print banded reports directly or email them as PDF files. Comma-delimited and extract reports deliver the data in various file formats, making it possible for users to easily work with the data outside of Argos.
Best Practices for DataBlock Design: Planning your DataBlock
Jumping into DataBlock design can be a bit overwhelming at first. There are many objects to choose from, and many more possibilities on how to use them. To make this prospect a little less daunting, we’ve put together a series of blog posts that will walk you through some best practices for helping you through each step of the DataBlock design process. In this first post, we’re going to address the first stage of DataBlock design: planning.
DataBlock Basics
Before we even consider the visual design of a DataBlock, it’s best to take a step back and think about the basic uses of a DataBlock. The Argos DataBlock is at the core of all development in Argos. A DataBlock serves three main functions:
- Run SQL –The DataBlock stores the majority of SQL scripts that will be used to retrieve and output the data your end users want to see. SQL scripts can be run through form objects, SQL variables, and the report query. While banded reports and extract reports allow the use of data sets with their own SQL scripts, generally the bulk of data retrieval will be done on the DataBlock side.
- The ability to select parameters – When you are retrieving data, these selections limit the result set. In many cases, end users are concerned with a specific set of information. Hard coding specific filters limits the possible uses of the DataBlock. Parameters give your DataBlocks the ability to answer more questions than one.
- Display results – Dashboards can be created to output results live, without the need to run a report. The DataBlock allows you to display data in multi-column list boxes, charts, and OLAP cubes. SQL variables can retrieve results and output them through data aware labels. While a DataBlock form does not have the same formatting options of a banded or extract report, a dashboard can deliver data in a quick and easy to digest manner.
From this, you can see that a DataBlock has three main components: the forms you will place parameters or output data on, the objects and variables themselves, and the Report Query that the DataBlock will use to run reports. With these uses in mind, you can then decide on how you want to build your DataBlock.
Specifications: What will this DataBlock include?
Before you begin work on a DataBlock, it is best to decide on what function this DataBlock will serve your end users. SQL and data specifications aside, some good design questions to ask would include:
- What kinds of output do your end users need?
- What parameters are relevant to the data you are selecting?
- What graphics and colors are required?
- What fonts are suggested or required?
- Are there formats required for the data you are outputting?
- Is there a template you can follow? If not, should you create a template for future use?
Determining the DataBlock type
Once you have a general idea of what needs to be output you can decide on what kind of DataBlock you will need to create. Here are some basic types of DataBlocks you can create, and their uses.
- Dashboard – A dashboard consists of the forms, parameter selections, and the means to output results only on the DataBlock side. Generally, a dashboard will not be designed with outputting the results in a formatted report. A dashboard is made to be a live, interactive means to quickly view results and analyze data.
- Report Generator – This type of DataBlock focuses on the parameters to run the report, if necessary, and the report query SQL script. In this case, the form(s) only serve the needs of the report. It’s not necessary to output data on the form.
- Hybrid – A hybrid DataBlock may output a report, but also has results and data shown live. It may be somewhat less involved than a typical dashboard as the data output on the dashboard may be related to the report query and the parameters used to output it. This way users can see the data live, but also save a formatted report if they desire.
- Application – There are many other ways to use a dashboard. You could use one dashboard to run various reports through report API calls made with ‘on click’ events. You could create an interface that allows you to do data inserts, updates and deletions. While you may think of Argos as only a reporting tool, we have seen clients implement DataBlocks that serve a much wider range of applications. Don’t immediately rule out what an end user may be asking you to do with Argos; it may actually be possible!
Don’t underestimate how useful it can be to ask the right questions about your DataBlock, before you even open Argos.
Best Practice for DataBlock Design Part II
from David Ramos, Report Developer at Evisions
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.
Best Practices for DataBlock Design Part III
from David Ramos, Report Developer at Evisions
When you’re building DataBlocks, it’s very important to keep in mind that you’re probably not the only one who’s going to interact with your DataBlocks. And even if you are, six months from now, you won’t remember what every piece of your design does, or why you designed it that way. Good naming conventions and clear descriptions can save other designers (or even just your future self) from confusion down the road.
Naming Scheme
Adopting a naming scheme can go a long way to help your DataBlock become understandable to other designers, and to yourself as you continue to develop. You can save yourself and others plenty of time if you follow some simple rules for naming your objects. As your SQL scripts will rely on these objects, name them as you are creating them. Don’t wait until after you have written all your SQL! Argos will not update the variable references in the SQL, and you may run into situations where your DataBlock will require quite a bit of editing to weed out every reference to a variable you may rename after the fact. A name also can tell you which form the object may be on, and what the object is allowing the user to select.
Here are some rules I follow:
For form parameters:
parm_Form_ObjectType_ObjectData
Example — parm_Main_DD_Term
First, I state that the object is a form parameter with ‘parm_’. As a reminder, no spaces are allowed in variable names, so an underscore is commonly used to separate words when naming.
Second, I will put the form the object is on. On DataBlocks with a single form, this may not be as important. If you have named your forms as well, simply put the name of the form here.
Third, I put the type of object as an abbreviation. For reference, I use:
BT (Button)
CB (Check Box)
CH (Chart)
DT (Date Entry)
DD (Drop Down List Box)
EB (Edit Box)
LB (List Box)
MB (Memo Box)
MC (Multi-Column List Box)
RB (Radio Button)
Other objects can be named in a similar fashion. However, labels, OLAP cubes, panels, scroll boxes and shapes are not truly parameters and do not show up on the Variables tab in the DataBlock editor. It may prove useful for you to name them, but it is less necessary than the other parameters.
Finally, I use a word or phrase that tells me what this object is showing me or allowing me to select.
For SQL variables:
sql_Form_VariablePurpose
Example – sql_Main_GetStudentID
I use ‘sql_’ to denote a SQL variable.
If a SQL variable is used on a particular form, I put the form name in the second position. If the SQL variable is not going to be used on a particular form, this may be omitted. Again, this is not as important if your DataBlock only has a single form.
Finally, as with objects, I use a short description or abbreviation that describes what this particular variable is doing. This helps distinguish the variable from all the rest.
DataBlock description
The last point I’d like to leave with you is to always clearly describe your DataBlocks and objects. This lines up with naming things properly, but design requires much more than that. To help with this, Argos allows you to put notes into the DataBlock. You can (and should) add a description to the DataBlock as well.
In your forms, you can use SQL and add labels to describe what an object does. Be as descriptive as necessary so that your end users don’t have to guess at what that object is doing. As an example, let’s say you make a selection for organizations. A list box that just has organization codes might be misleading. In the SQL you can add the account description as well to display for the user. Adding a label above the list box that says “Organization:” might be enough. However, if you could select more than one account, with a small edit to make the label say “Select Account(s):” you can clue your users in to the fact that you can select more than one account without writing explicit instructions.
If your users do need steps or instructions, considering adding an extra form they can reach where you can provide detailed instructions. On the other hand, maybe a short description near the selections is all the end users need. Your end user feedback will help you find the right level of information to include or exclude from your forms. You need to strike a balance between being informative and creating a simple and clean interface without the clutter of instructions.
Remember: You are the designer
While I can make suggestions and provide these tips, nothing in design is a hard fast rule. Each institution I’ve worked with has had different ideas, needs and rules. Meeting the needs of your end users is always key here. Communicate with your end users to get a feel for what they need. Be open to feedback, and always be willing to try something new to take your DataBlock design to the next level.
I would like to see logins and resources for:
For a general list of frequently used logins, you can also visit our logins page.