SDSHOWTO:Survey 2011 Responses
Reference Material
- SDS: http://sds.smus.ca
- SDS Beta: http://sds-beta.smus.ca
- Submitting a request: Email sdshelp@smus.ca
- Viewing the status of your requests: http://secure.smus.ca/rt
- SDS Roadmap: https://secure.smus.bc.ca/wiki/index.php/SDSHOWTO:Roadmap
- SDS Changelog: https://secure.smus.bc.ca/wiki/index.php/SDSHOWTO:Changelog
Multiple Choice Questions
The SDS is easy to use
Strongly Agree (5): 9 Agree (4): 29 Neutral (3): 7 Disagree (2): 13 Strongly Disagree (1): 3 Average: 3.46 Responses: 61
We're doing our best to improve usability. As we continue to add functionality to the SDS, it gets more difficult to present all of the options available. Some of the pages in SDS are quite old and do not follow our more recent usability guidelines, but we're improving those as we find time. Please let us know if you have any specific suggestions on how to make the page you use most easier to use.
Finding information using the SDS is fast
Strongly Agree (5): 9 Agree (4): 21 Neutral (3): 15 Disagree (2): 14 Strongly Disagree (1): 2 Average: 3.34 Responses: 61
Similar question to the last one, and a similar response. Again, any specific suggestions please let us know.
When I click on something, the SDS shows the next screen quickly
Strongly Agree (5): 14 Agree (4): 34 Neutral (3): 9 Disagree (2): 4 Strongly Disagree (1): 0 Average: 3.95 Responses: 61
The responsiveness of the SDS depends on several factors, including how many people are trying to use the SDS at the same time as you, how complex the page you're trying to load is, how fast your local computer is, and what web browser you're using.
Some things you can control: a laptop will generally load the SDS slower than a desktop. Internet Explorer version 8 and below tend to load the SDS slower than other web browsers, so it's better to use Firefox, Safari, Google Chrome, etc. when using the SDS. Over the summer, the MIS department will be pushing out Internet Explorer version 9 to the Windows 7 desktops and notebooks, which will make things load faster if you still prefer Internet Explorer.
We try to keep the SDS response time below 1 second, so after you click on something, it should always take less than 1 second to come back with the next screen. Some admissions statistics pages take longer than 1 second, but they're loaded infrequently and also process ~5000 students at once. Most pages are well below this threshold (for example, the front page of SDS takes ~ 0.15 seconds). If you try the page under SDS Beta and scroll down to the very bottom of the page, it tells you how long the page took to load (in seconds) like this: "Page generation time: 0.189" Please let us know if you find pages that consistently take a very long time to load and we'll look into speeding them up.
The SDS helps me to do my job
Strongly Agree (5): 15 Agree (4): 28 Neutral (3): 15 Disagree (2): 1 Strongly Disagree (1): 2 Average: 3.87 Responses: 61
This is the most important question for us, as the reason for the SDS to exist is that it makes your job easier. If we're not meeting your needs, make sure to send in a request to get the SDS changed so it works for you.
The SDS is essential to do my job
Strongly Agree (5): 17 Agree (4): 25 Neutral (3): 13 Disagree (2): 4 Strongly Disagree (1): 2 Average: 3.84 Responses: 61
We try to make the SDS fast and easy to use, especially for the people who must use the SDS in order to do their jobs. In particular, there are some admin staff who are the only people to use their section of the SDS, and yet we must still make their module fast and easy to use so that they can do their job. This specialization will continue to increase as we integrate more functionality into the SDS.
I only use the SDS because I have to
Strongly Agree (5): 6 Agree (4): 17 Neutral (3): 15 Disagree (2): 17 Strongly Disagree (1): 6 Average: 3.00 Responses: 61
This one is particularly interesting, as the people who disagree are balanced with the people who agree.
I frequently experience errors when using the SDS
Strongly Agree (5): 2 Agree (4): 6 Neutral (3): 13 Disagree (2): 32 Strongly Disagree (1): 8 Average: 2.38 Responses: 61
We're glad most people disagree with this one! Any time you receive a fatal error from the SDS, we get emailed, which is a strong incentive for us to correct the errors. There are several other types of errors that we do not currently receive emails for, though, and we'll be working on developing a way to receive these in the future, too.
Information I put into the SDS is secure
Strongly Agree (5): 5 Agree (4): 29 Neutral (3): 25 Disagree (2): 1 Strongly Disagree (1): 1 Average: 3.59 Responses: 61
The SDS developers must deal with several "non-functional" requirements when programming the SDS. Unlike adding features or fixing bugs, non-functional requirements involve qualities of the system, like how fast it should run, how many hours a day it should be available, how secure it should be, etc. Security is one of the most difficult to get right, as many large companies find out every year. Now that we are giving parents access to some of the information stored in SDS, we must be even more careful about information disclosure.
The SDS is designed with security in mind. Each different screen in the SDS is secured separately, meaning that we can list exactly who has access to each page. Additionally, we enforce that users must be logged in to access most pages of the SDS, and ensure that non-authenticated pages are limited in the information displayed. Critical errors are configured to not display any "debugging" information to the user (although we receive the debugging information by email) as per best practices. We are scanned quarterly by a PCI-DSS certification company to verify that we do not have any obvious security flaws in our server architecture. We also do internal scans with a vulnerability checking tool called Nessus. User passwords must be changed every 90 days, and must satisfy complexity requirements. Any change to SDS data is logged and we can (and have) go back and figure out who changed a value in the system. Logins, impersonations, unimpersonations, and certain functions are also logged. Impersonation (which carries one of the greatest risks for information disclosure) does not grant any extra permissions over what the original user had.
The SDS is available whatever time of day or night I'm trying to use it
Strongly Agree (5): 22 Agree (4): 30 Neutral (3): 6 Disagree (2): 3 Strongly Disagree (1): 0 Average: 4.16 Responses: 61
Other than our maintenance period (Fridays from 4:00 pm until 5:00 pm), we try to ensure that all sections of the SDS are available at all times. We have set up several monitoring systems to alert us whenever anything goes wrong (services go down, errors are encountered, etc.) to get things up and running again as soon as possible if something does break.
The * section is easy to use
The attendance section is easy to use: Average: 3.7377 The awards/voting/ROA section is easy to use: Average: 3.2459 The calendar section is easy to use: Average: 2.8033 The reports section is easy to use: Average: 3.5410
Clearly we have more work to do on the calendar section. Please see my responses in the "Short Answer Questions" section to specific complaints regarding the calendar. The awards section has been upgraded a bit, so granting ROAs should be a bit easier than last year. Make sure you use the course-specific award granting link, as that will filter the list of students down to just the ones in your class.
The * section is useful
The markbook section is useful: Average: 3.0417, Count: 24 The lesson planner section is useful: Average: 2.9545, Count: 22 The advisor section is useful: Average: 3.2051, Count: 39 The impersonate function is useful: Average: 4.0833, Count: 60 The resource booking function is useful: Average: 3.5000, Count: 58 The search function is useful: Average: 3.4655, Count: 58 The "show student info" function is useful: Average: 4.1333, Count: 60 The "canned reports" function is useful: Average: 3.4146, Count: 41
The responses to these questions help us to prioritize what sections we should improve and provide additional information on. If you are a teacher and didn't know that the SDS had a markbook or lesson planner module, talk to Richard and he can show you how it works. The canned reports section allows you to generate many of the same reports that Gisele can print for you, and is available under Administration -> Canned Reports in the sidebar.
* is important to me
SDS security is important to me: Average: 4.4426, Count: 61 SDS speed is important to me: Average: 4.4754, Count: 61 SDS aesthetics are important to me: Average: 3.7213, Count: 61 SDS bug fixes are important to me: Average: 3.9836, Count: 61 New SDS features are important to me: Average: 3.7705, Count: 61
This exactly reflects our existing hierarchy of SDS change priority, except we currently group speed tweaks in with bug fixes. So, if a security issue is found, we fix that before anything else, and fixes to the visual layout are prioritized last. We will put more focus into increasing SDS speed.
If you were the person deciding which priority to assign to incoming requests, how important would the following factors be?
How many people are affected by implementing the request: Average: 4.0000, Count: 61 How much time each individual person will save: Average: 3.7705, Count: 61 How much time the school will save as a whole: Average: 3.8197, Count: 61 How many different people have asked for the same feature: Average: 3.5738, Count: 61 How long it would take to program (and how long everyone else will have to wait for their request): Average: 3.0000, Count: 61
This mostly reflects the approach we take to prioritizing requests, except we also take into account how long the person asking for the request has been waiting, what time of year it is (longer requests that will impact SDS stability are typically attempted over the summer when fewer people will be inconvenienced if something isn't quite right), etc.
Features we're hoping to get to this summer include:
- Start implementing online forms for parents to fill in, rather than sending out the forms package every year (we'll be piloting with one consolidated health form rather than large number we typically send out)
- Merge the re-reg application into SDS
- Implement grade advisor start-of-year appointments through the parent portal
- Update PLO-based reports so that they can have different evaluation criteria per campus
- Ability to check graduation requirements (per student and at the university counselling level) to verify that all students have the prerequisites to graduate
- SDS version of service tracking (Rob has been working on a prototype for quite some time now, and we think we have a close to final design)
- Put AUP signoff and reporting into SDS
- Education extension listing, registration, and payment online as part of the SDS
- Update the calendar trip workflow so that additional data is collected through SDS as part of the approval process
- Weekend leave online management
- Junior school parent/teacher interview signup and scheduling
As you can see, we will be very busy this summer!
Yes/No Questions
Do you ever consult the SDS help in the top right corner?
Yes: 8 No: 53
Would you use the SDS help more if there was more/better information?
Yes: 34 No: 27
Would you contribute to the SDS help section by writing instructions?
Yes: 18 No: 43
Help is always a difficult topic. It tends to only be useful when you're trying to do something for the first time, or if you haven't done something in a while. In those cases, it's nice to have a set of step-by-step instructions to follow to accomplish a task. The IT department documents most of our procedures online so that we can refer back when necessary, too. Unfortunately, keeping the SDS' 500+ help documents up to date is a large task, especially as we are also supposed to be adding new features and fixing bugs!
Instructions are difficult to write if you do not use the page for its intended purpose. A programmer accessing the attendance page, for example, isn't going to operate the page the same way as a teacher accessing the attendance page. It is most beneficial for peers to write the help contents.
Help documents are easy for us to publish. If you send any help content to sdshelp@smus.ca, we will put it onto the help page as soon as possible. This is a great way for you to help your peers accomplish their SDS tasks.
Do the problems you experience eventually get fixed?
Yes: 28 Sometimes: 31 No: 2
Do the problems you experience get fixed quickly?
Yes: 15 Sometimes: 43 No: 3
Management of the request queue is a difficult part of our job. There are currently 261 open requests in the SDSHelp system (and 561 resolved requests!). Of these tickets, we prioritize based several factors (discussed above) and then work away at the queue as new requests come in. Some requests are easy and take a few minutes, while other take several days or weeks. Our best estimates at the moment indicate that there are approximately 2-3 full years of work in the queue right now, and that doesn't include any other requests that come in while we work on the existing ones.
We try our best here, but there is always room for improvement. If something is really important and needs to be fixed right away, please make sure to tell us that. On the flip side, if something is nagging at you but you can live without the change, please indicate that as well so that we can tuck it away to deal with during a logical break between other requests.
Some requests will not get dealt with until we receive additional information from the original requestor. If you've received a question from us, the request goes into a separate queue ("stalled") until you get back to us with the information we need. If you're unsure of whether any of your requests are stalled, please check the status of your requests here: http://secure.smus.ca/rt
Do you notice when new versions of the SDS are released (usually every 4 weeks)?
Yes: 20 Sometimes: 22 No: 19
Do you read about what has changed?
Yes: 6 Sometimes: 34 No: 21
For the past couple of years, we have tried to keep a regular and predictable release cycle for the SDS. Some people want changes affecting them to be available right away, while others prefer that things change as infrequently as possible, as they're used to what they have now. To satisfy the first type of person, we would need to adopt a "continuous integration" model where every time we changed something or made an update, we would make it available on the production SDS immediately. This is also known as anarchy, as there is no opportunity to verify that the changes work correctly or let anyone know about the feature in advance. The long-term release preference is much easier for us, but since more things have changed, more testing is required and everyone has to wait for 6-12 months in order to use the feature they requested.
In order to balance those two opposing methods, we have adopted a 4 week release cycle. Every 4 weeks, we gather up all of the changes we have made to the SDS and put them live all at once. This allows us to test the changes first (1 week before the release, we have a beta testing group check through the changes and make sure that the functionality they use isn't negatively affected by the changes) but still results in a reasonable lag for the availability of fixes.
We do our best to tell you what has changed in each release. It is difficult to indicate to everyone what is relevant to them, and the feedback we have collected throughout the years has reflected this. We now group the changelog into sections of the SDS to help you identify what changes are important to you. We also try to use accessible language for most of the categories, except the "System" category which deals with backend changes that aren't really relevant to anyone but the developers. Many of the changelog items also have a request tracker number associated with them, so if you sent in a request and got back a number, you can check to see if your request is included in each release.
Have the last few months of SDS changes affected you?
Yes: 30 No: 31
We try to include fixes for a wide variety of requests in each release so that there's something for everyone. This gets more complicated when we're working on larger changes, such as the resource booking reimplementation and online forms for parent portal.
Have you ever used SDS Beta?
Yes: 26 No: 35
The SDS developers will commonly refer people to SDS Beta to check that changes have been implemented correctly, or to help test during the one week pre-release beta period. We rely on the beta testers to check that the functionality they use isn't broken by changes we have made to the system. This is an extremely important part of the development process, and appreciate all of the help we receive from the beta testers.
If you would like to help test/preview a release, please send us an email at sdshelp@smus.ca and we will add you to the group.