SDSHOWTO:Survey 2011 Responses

From SMUSwiki
Jump to navigation Jump to search

Quick Reference

Introduction

Thank you for filling out the 2011 SDS Survey. The statistics that we have obtained, along with the comments and requests that have been gathered, will help us continue to improve the SDS for everyone. Below, we have summarized the information collected. We have also gathered up the short answer comments that were left and provided some responses.

There were several reasons for us to run the survey. First, we wanted to confirm that our development processes and prioritization methodology were in line with the opinions of users of the SDS. Second, we wanted to determine what sections of the SDS are most frequently used, and which sections of the SDS that our users think are the most important. Third, we wanted to ensure that the people using the SDS had a say in where the SDS goes from here.

As you may or may not know, the SDS started as a collaborative project with Brentwood College School. We recently ended the collaboration agreement, meaning that everything we add and change in the SDS is now SMUS-exclusive. We have updated the copyright statement and credits on the SDS footer to reflect this as well.

62 people filled in our survey. We believe that this is a representative sample of the staff and faculty of the school. We did not collect personal information, and so do not know how many faculty vs. staff filled in the survey, or whether each campus was proportionally represented.

Multiple Choice Questions

The SDS is easy to use 

Strongly Agree (5): 9
Agree (4): 29
Neutral (3): 8
Disagree (2): 13
Strongly Disagree (1): 3
Average: 3.45
Responses: 62

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): 22
Neutral (3): 15
Disagree (2): 14
Strongly Disagree (1): 2
Average: 3.35
Responses: 62

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): 35
Neutral (3): 9
Disagree (2): 4
Strongly Disagree (1): 0
Average: 3.95
Responses: 62

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, as they're less powerful. 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 accessing 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): 29
Neutral (3): 15
Disagree (2): 1
Strongly Disagree (1): 2
Average: 3.87
Responses: 62

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): 18
Agree (4): 25
Neutral (3): 13
Disagree (2): 4
Strongly Disagree (1): 2
Average: 3.85
Responses: 62

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 effectively. 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): 16
Disagree (2): 17
Strongly Disagree (1): 6
Average: 3.00
Responses: 62

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): 33
Strongly Disagree (1): 8
Average: 2.37
Responses: 62

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. If too many people are hitting an error, we will usually create a "point release" specifically to fix this issue so you don't have to encounter the error for 4 weeks until the next release.

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): 30
Neutral (3): 25
Disagree (2): 1
Strongly Disagree (1): 1
Average: 3.60
Responses: 62

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. Access to the SDS automatically times out after 30 minutes, although if you try to do what you were doing anyway and log back in when prompted, you can usually continue without any interruption to your workflow. 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): 23
Agree (4): 30
Neutral (3): 6
Disagree (2): 3
Strongly Disagree (1): 0
Average: 4.18
Responses: 62

Other than our maintenance period (Fridays from 4:15 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 help 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.76
The awards/voting/ROA section is easy to use: Average: 3.27
The calendar section is easy to use: Average: 2.82
The reports section is easy to use: Average: 3.53

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. If you have any suggestions on how to improve the calendar section (other than the ideas already discussed in the short answer section), please email sdshelp@smus.ca. 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.04, Count: 25
The lesson planner section is useful: Average: 2.96, Count: 23
The advisor section is useful: Average: 3.20, Count: 40
The impersonate function is useful: Average: 4.07, Count: 61
The resource booking function is useful: Average: 3.51, Count: 59
The search function is useful: Average: 3.49, Count: 59
The "show student info" function is useful: Average: 4.15, Count: 61
The "canned reports" function is useful: Average: 3.40, Count: 42

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.44, Count: 62
SDS speed is important to me: Average: 4.47, Count: 62
SDS aesthetics are important to me: Average: 3.74, Count: 62
SDS bug fixes are important to me: Average: 3.98, Count: 62
New SDS features are important to me: Average: 3.76, Count: 62

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 as people report pages that load slowly.

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.01, Count: 62
How much time each individual person will save: Average: 3.77, Count: 62
How much time the school will save as a whole: Average: 3.82, Count: 62
How many different people have asked for the same feature: Average: 3.60, Count: 62
How long it would take to program (and how long everyone else will have to wait for their request): Average: 3.02, Count: 62

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!

We keep a list of the upcoming major projects on the SDS Roadmap so it's easier to predict when features will become available.

Yes/No Questions

Do you ever consult the SDS help in the top right corner? 

Yes: 8
No: 54

Would you use the SDS help more if there was more/better information? 

Yes: 35
No: 27

Would you contribute to the SDS help section by writing instructions? 

Yes: 19
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.

UPDATED INFORMATION (May 30, 2011)

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.

YOU can now edit the help information on each page of the SDS! Here is how you go about doing this:

  1. Open a help document in the SDS by clicking the red "Help" link in the top right corner
  2. Scroll to the bottom of the help document
  3. Open the "retrieved from" link in a new tab or window. In Firefox, right click the link starting with "http" and choose "Open link in new tab"
  4. Log into the Wiki using your standard SMUS username and password
  5. Click the "Edit" tab and edit the help file using Wiki markup: http://en.wikipedia.org/wiki/Help:Wiki_markup
  6. Save the page, and the new help file will be immediately available for others to view through the SDS

This is a great way for you to help your peers accomplish their SDS tasks.

Do the problems you experience eventually get fixed? 

Yes: 29
Sometimes: 31
No: 2

Do the problems you experience get fixed quickly? 

Yes: 16
Sometimes: 43
No: 3

Management of the request queue is a difficult part of our job. There are currently 274 open requests in the SDSHelp system (and 565 resolved requests since February 2010!). 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 survive 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: Request Tracker.

Do you notice when new versions of the SDS are released (usually every 4 weeks)? 

Yes: 20
Sometimes: 23
No: 19

Do you read about what has changed? 

Yes: 6
Sometimes: 35
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 approaches, 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 and relevant 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 the release.

Have the last few months of SDS changes affected you? 

Yes: 31
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. The fact that 50% of users have noticed a change in the past few months is evidence enough that we're performing adequately here.

Have you ever used SDS Beta? 

Yes: 26
No: 36

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. If an issue isn't picked up during the beta testing period, the fix either has to wait for the next release (4 weeks), or we have to do a "point release" to correct the single issue. As creating a point release takes a significant amount of manpower and takes us away from making changes to the next release, it's much better to find the issue during the beta testing period.

Beta testing 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.

Short Answer Questions

If there was one feature you could add to the SDS that is not currently present, what would it be?

Day 1 - day 10 classroom schedules like we used to be able to get from Trevlac

These are now available for all staff under Calendar -> Print timetables.

Being able to e-mail the parents of a class without going to the master list of parents

I'm not sure I totally understand the request, but here's how I would do this:

  1. Expand your course, then choose "Email students"
  2. Click the "Email parents" button
  3. This page looks like the master list of parents, but actually it's already filtered down to just the parents of students in your class
  4. Any additional filters, like looking for day students to supply camping gear or whatever
  5. Click the "Send email to checked recipients" button

Medical forms that I can download

Ability to have parents (especially of boarding students) complete forms online

Ability to create address labels without groing through the e-mail parents feature, often the reason a label is required is because there is no e-mail address on file.

off-campus paperwork linked to calendar stuff

the school's WHOLE trip planning system should be stream,lined through the SDS.

When I enter in an off-campus trip is would provide all of the useful information in an appropriate format. In order to book an off-campus trip I currently need to complete three or four things and most of this info is located in the SDS.

overnight/long-weekend leave forms

WEEKEND LEAVE AND LONG WEEKEND FORMS

long weekend leave forms

There are all summer projects, and we're hoping to implement them by the start of the 2011/2012 school year.

a bit more of the blue book info

Parent's occupation (like the Blue Book)

More info that used to be in the bluebook about parents and their occupation, etc.

easier to access report history without changing the date

We're looking at adding historical report cards here, as parents already have access to archived report cards including the Trevlac ones. Just a matter of actually adding the download ability to this page. We have created a request to add parent occupation to the show student info page.

So that all sections of one facility area can be seen on one screen rather than one section at a time

I'm assuming you mean sds "Resource booking" (what we call it). We have the ability to group together resources into "room groups" that allow you to check on all of those rooms at once. To get there, expand "Resource Booking" and click "Room Groups". The default view is a daily view of all of the senior computer labs, so you can see if any one is free for the period you teach in. You can look at other groups by dropping down the group box at the top.

It's quite easy to add additional room groups, I just need to know what groups are useful to people (email us!).

Being able to select multiple students for entry into things like Friday night prep.

It is possible to do this right now. When on the prep signup page, hold CTRL (or command on Mac) and click on each of the students you would like to assign to prep. When you click the "Add" button, all of the students you selected will be added to the prep you chose.

Customizable home for each login. Don't want to look at all the non relevant calendar on the main page.

Better display on the home page of all the school events.

I would like to change the look and feel of the program. All of the important information is crammed on the left hand side, and the main section of the screen is not useful. I would like my timetable or day laid out interactively on the main page (make the main page personalizable).

This is surprisingly complex to implement, as each person we ask wants something different on the front page. We are looking into a "My SDS" portal view that shows different items in blocks that you can add/remove.

Gym booking/squash booking, with multiple gym/court views, and booking capabilities

This is available through Resource Booking, by expanding Resource Booking and choosing "Room Groups." Select "Gyms," "Playing Fields," and "Squash Courts" to see each of these groups of resources. If it is desired, we can also add a group of all of these together for PE booking, but you will have to scroll left-to-right because of the number of resources listed.

more flexibility in label formating

This is surprisingly difficult, for the following reasons

  1. We have to guarantee that all of the label content will fit on a label. Whenever we create labels, we make the text the maximum size possible that fits all of the potential information. This is a big problem, for example, on address labels, where the parent could have multiple lines of address, a country, a mailing language, several students, etc.
  2. When a label is printed that doesn't have all of the lines we expected, we don't make the text bigger so that all of the labels are printed uniformly.
  3. The coding library we use to generate PDF files with labels (even labels sent directly to printers are transformed through PDF files first) does not use standard fonts (.ttf files). It instead uses Adobe fonts (.afm files), which are much less common and less widely available. This limits our options, and so we've chosen Helvetica in most cases because it's the most readable at small font sizes.

Make options more intuitive and quickly visible by using representative icons in addition to mouse-over text display.

I would love to do this, but will never have the time. If someone wants to draw me an icon set for all of the functions in the SDS (there are 532 individual pages in the SDS, and most pages have several actions that can be performed) please email sdshelp@smus.ca and we'll sort something out.

A more user-friendly interface design such as the LearnNowBC website.

As I am not a graphics designer, the marketing department has been asked to assist with this request. Restyling the SDS is a difficult task, as there is a very large amount of information to present, and we need to maximize the amount of space available to present that information. In the past, we have tried to take a minimalist approach to layout and design to ensure that the page content is the focus, but we will be revisiting all assumptions when looking at a graphical redesign.

give parents the ability to look up contact info for other families

This is a security issue more than anything else, and once we have finalized exactly who should have access to what, we can start implementing this.

A quick email link from the attendance area that drafted an email straight to the attendance person, formatting the students name, the class and the date

Is this for "Absent (Unexplained)" absences? If so, the data center automatically emails these students so that they come in and resolve the attendance issue, so you shouldn't have to track them down yourself. If you want to email your absent (explained) students, we would need to add a feature like this.

That the active apps could allow a notation beside it that a connection was made with the person who applied.

I have created a request for this one.

The ability to see parent's addresses without having click "email parents" (I almost exclusively use outlook so that I have a record of the email sent in my sent mail)

I'm assuming we mean email addresses here. In order to implement this request, I would need to know where you need to see the email address. Email addresses take up a large amount of room (because they can be very long and we have to design the display to accommodate this), so some pages will not have enough room. If you send an email through the SDS, by the way, it emails you a copy with the list of who you sent it to at the bottom. You can take this message (which appears in your inbox) and drag it to your Sent folder for safekeeping.

ability for boarding students to live view their attendance (The data is there and staff can view - this shouldn't be too hard)

I have created a request for this one.

to be able to send emails to a student, his/her parent(s), homeroom teacher, grade advisor with one click

We have many different email grouping requests. All of them have been sent to Rob. He is compiling a list of all of the different requests so that a single solution can be implemented that satisfies everyone. Some people think that the student's parent should be their houseparent while they're a boarder on campus (but it should flip back to their actual parents during breaks), while some people want to email the boarding student's actual parent even when they're on campus. Other requests want to email all of their parents (including secondary parents, emergency contacts, etc.) and some only want to email the parent that the student lives with. There are many, many variations here.

At the moment, the SDS does not store who the grade advisor is for each student, but this should be resolved over the summer.

house of every border with houseparents name

I need to know where this information should be displayed. Please email sdshelp@smus.ca.

attendance for the experiential kids

When the experiential students start doing their experiential program (off campus all day, not attending their regular classes), the ability to do attendance through SDS stops. There are several reasons for this:

  1. The students are not de-registered from their standard courses. If we were to create experiential program courses, they would all conflict with their existing course registrations.
  2. The students are not always in the same course at the same time each timetable day. This makes it impossible to schedule them into blocks like regular courses.
  3. Students are often off-site, and the teachers do not bring internet-connected devices with them to take attendance through the SDS.

We're trying to come up with a way to allow attendance, but it's difficult and some changes would be necessary to the way the experiential program is scheduled.

The flexibility of custom designing reports, and fields to be included, would be helpful.

There are many options for creating customized reports through the "Canned Reports" module, specifically the "Output Index" page. Go to Administration -> Canned Reports -> Output index and play around a bit. It's a very complex page, but you can generate some very useful reports from here. Otherwise, if there are more complex queries you need to do (like reporting with MS Access, or a new PDF report), contact us at sdshelp@smus.ca and we'll make something work for you.

Being able to shortcut features that are used often on the home page would be great.

We typically depend on your web browser to do this. For example, you can bookmark a page that you frequently access in the SDS. If you try to access it and haven't yet logged in, you can go there, log in, and be taken to the page you want. Additionally, with Firefox, you can drag a sidebar link to your bookmarks bar and it will be available in a similar way. Tasks you access frequently in the SDS will also be added to the "Commonly Used Pages" at the top of the SDS sidebar.

The ability to "speak" or integrate with the other databases used in the school, so that all our student/parent records are uniform, that global changes can be made and the necessity to update information in several dbases is unnecessary

This is probably the most difficult request out of all that we have ever received (and we have received it several times). Unfortunately, it is a virtual impossibility at this point, as each system stores its person information differently, and has different limitations on how many people it can store per family, how the families are set up, how the addresses are stored, etc.

We are working to make the updating process easier, though. Over the summer we will be implementing the ability for parents to request an update to their information through the parent portal. This will be sent as an email to Gisele (to update the SDS), and we can also email the maintainers of the other database systems at the same time so that they also update their information.

i would redo the facilities booking section.

We did just redo the resource booking section (based on years of feedback about the previous system), so this is unlikely to happen for quite some time. If you have any specific suggestions or requests, please email sdshelp@smus.ca.

a common input for calendar. I.E. if you put it in there, it can feed into announcements, school calendar etc without having to email others the same info

The infrastructure for this is in place (you see announcements, bus requests, etc. on the manage events page), but we just have to convince everyone that they should start using it. We are working towards getting the SDS announcements section up onto the digital signs around campus and should eventually be able to replace the outgoing email with the SDS announcements section. Bus requests need a bit more SMUS customization, but then you will be able to manage those from SDS too. We're working on moving the rest of the calendar approval process into SDS, which will simplify those steps as well. One day, you will be able to enter the information once and have it translate to all of the necessary sections.

make the calendar view modifiable so that a person can filter out the irrelevant information

This is possible with the current version of the SDS. Bring up the (for example) monthly calendar. There is a blank dropdown above the calendar, which you can pull down and filter the calendar to a specific category rather than all of the events. We're working on additional customization here, such as filtering by multiple categories.

I would like it allow us to send copies of e-mails, within the school, simply by typing the name of the person

I'm assuming this is from the standard SDS email page. Generally you can do this by typing firstname.lastname@smus.ca into the "To" box at the top of the email page, but I'll look into adding some sort of quicksearch functionality here.

I would like students to be able to e-mail me all their test and assignment dates easily from SDS.

We're actually looking at implementing this in reverse, so teachers can view their students' upcoming tests and SDS assignments directly.

There should be a box/space allow subject teachers to make a note for a student on the attendence page so that subject teacher do not need to send a seperate email to Gisele to say, "I marked Tom absent today but he emailed me yesterday, said he will be .... "

Brentwood has a checkbox to indicate that even though the absence is unexplained in SDS, the student had already arranged to be away, but we removed it at SMUS. I'm not sure of the reasoning behind that, but it should be pretty trivial to put it back.

UPDATE FROM GISELE (May 30, 2011):

The problem with this is that I will not know the reason the student gave for not being in class. Some teachers excuse students for reasons that the Ministry will not accept as an excused absence, so it must remain in the system as not excused.

She prefers the textbox approach, but it would still mark the student as absent (unexplained) until the reason has been reviewed.

What web browser do you use to access the SDS

It appears that most people are using Internet Explorer to access the SDS at school. At home, many more people use alternative browsers (such as Firefox, Safari, and Chrome).

Firefox is available at school, but it is launched a little bit differently than at home. We deploy "Frontmotion Firefox Community Edition" at SMUS, as that allows us to set the preferences necessary for operation in the school environment. There is usually an icon on the desktop to start it, and if not, you can run it from the Start Menu (under "Frontmotion Firefox"). I generally recommend that the SDS is accessed through Firefox, as that's what I use when I'm programming it (I'm currently programming against Firefox 4.0.1). Google Chrome and Safari are both very standards-compliant, and shouldn't have any issues with the SDS.

Internet Explorer 8 and below (8 is currently deployed to all SMUS computers) are slower at drawing the SDS content, and I do not test them when programming the SDS. Internet Explorer 9 is better, and will be pushed to all school Windows 7 machines this summer.

What hardware platform do you usually use to access the SDS?

It appears that there is a good mix of desktop and laptop use. A few people mentioned tablets, and very few people use smartphones. I do know that using the SDS on a smartphone is particularly aggravating. Of course, the most aggravating part is that the screen is very small and there are way too many options, so we looked at creating a reduced functionality SDS (such as just attendance and show student info sections) to access through the smartphone. Unfortunately, it would have taken a lot of work, and the number of smartphone users at SMUS means that we probably won't be implementing that in the near future.

Please provide any additional comments you might have

We appreciate the positive feedback provided in this section. While it is not reproduced here, know that we've read all of it. Thank you!

I think we should be taken directly to the log in screen and bypass the initial screen where you click on log in

You've got a couple of options here that will allow you to do this.

  1. Bookmark the following page: https://sds.smus.bc.ca/index.php?next_page=login.php (if you're taken to the main SDS page, log out of the SDS and then go to the link again)
  2. Bookmark the actual page you want to bring up. If you're logged out of the SDS and go to that page, it will ask you to log in and then you will be taken to the page you want. You can, for example, create bookmarks to the attendance page for each of your courses and use those bookmarks to go directly there after logging in.

Frustration felt by myself is when a change is made but things are not quite "right" (i.e. room booking) and you have to wait weeks for it to work as good as the old system

Also I find after a release of an update...SDS usually breaks down again in some other area which is frustrating.

We have a very long-term initiative in the SDS development to create "unit tests" for the SDS. This will allow us to automatically test whether a change we have made has a chance of breaking other functionality that is dependent on the same code. However, that is a long way out at this time, because the changes required are very intrusive and the amount of work required is measured in months. Until then, we must rely on our beta testers to find problems and provide feedback on the changes we have made.

One way to help us here is to join the beta testing group and help out with testing. Email sdshelp@smus.ca if you would like to be a beta tester.

another frustration is that Chris takes it upon himself to make policies regarding documents etc... and we have to fight with him (pointlessly) to get what is needed - his job is to make sds functional, not to make policies and enforce them...

I usually try very hard not to create policies without consulting with other people at the school first, however in certain cases I will make a decision directly:

  1. A security issue is actively causing problems and needs to be fixed immediately. I will make the lowest impact fix without consulting anyone or having people test it.
  2. When I am asked or told to make a decision regarding development direction, software architecture or security.
  3. When a decision has previously been made that would also apply to the new question.

I will also provide my opinion when others are discussing policy decisions.

As far as incoming requests go, I try my best to categorize and prioritize each request. When a request comes in, we evaluate its priority compared to other requests and also try to gauge the feasibility of implementing the request. In some very rare cases, requests are rejected because they will take too long (compared to how much benefit is gained from implementing the change) or because of some other technical requirements or issues. In total, 13 requests out of 852 have been rejected.

The issue with the fixes is that it is difficult to know what you should be testing and in what release they will show up in? There are so many fixes as this system is a 'build as you use it' and it is very challenging to figure out what fix is in what release

When I close a bug, I always write something like:

This has been fixed for SDS 4.9.0 (to be released on May 7th)

I think this is pretty clear, but if you have any additional suggestions or requests, please email sdshelp@smus.ca.

When we get beta testers to check a release, I also send out a descriptive email detailing what has been changed and what sections should be tested.

I find the reports gathering frustrating and worrisome. It could look better.

There is a huge amount of information necessary when writing a report, so we do our best to display it all. The report writing section hasn't ever received a facelift, so we probably would design it differently now. If you have any specific feedback, please send requests to sdshelp@smus.ca and we'll take a look. Otherwise, we will probably look at overhauling the reports page eventually with a lot of feedback from teachers.

So for example, the white writing on the black background takes longer to decipher than the reverse because of our habitual reading environments.

The Brentwood SDS uses a light grey background for the sidebar and black text. I believe that the sidebar display was changed for SMUS so that it looked more "SMUS-ish", but it's quite simple to change.

I could probably use a refresher or SDS. There are some functions I know nothing about, such as the calendar, lesson planner. There might be more ways that I can benefit, and it is nice if someone can take the time to show me how i could benefit more.

We're looking at doing more education on how to use SDS. Please submit suggestions for training topics to sdshelp@smus.ca and we'll see what we can do!

If there was someone else around to do the work in the SDS it may have resulted in less work overall.

Editor's note: this is referring to the service tracking module that Rob P. developed

SMUS has invested a lot into SDS, and it's fairly unlikely another full-time programmer will be brought on to work on SDS. That said, with a large module such as service tracking, it's quite useful to have a prototype system developed that helps to weed out issues and clarify requirements before the production system is implemented. Rob's work on programming a service tracking module was not wasted, as we now have a great design to work off of when writing the SDS version.

I find charging students for books, for example, difficult and confusing

This is an unfortunate by-product of how the charges system was designed initially. All that is necessary for a charge is to come up with a list of students, a price to charge each student, and an account to put the money into. This was originally implemented as an add-on to the Calendar system, as that was a place that we were keeping lists of students, and quite often charges were applied as a result of a calendar trip.

As part of the calendar/event system rewrite, we set up the charges in the same way, so that they were part of the event/calendaring system. Again, we did this because quite often a charge is a result of a calendar trip, and we already keep around lists of students in this module.

We can probably add another link somewhere in the sidebar that takes you to the events page to remind you that this is where you want to go to do a charge. The old link to charges wizard was removed when the calendar system was rewritten.

Having some things still on the old system is maddening. I hate that I use moodle, sds, and the Smus intranet -I can't imagine how new users to the school feel about it!

Unfortunately, each of these systems does something that the others do not. We're trying to move a lot of the Intranet content into SDS, but there will always be some (such as policy documents) that will likely stay there. Moodle is great for class management, online assignments, hosting course material, etc. that the SDS cannot currently do.

Also probably aggravating is that you have to log into each one of these systems separately. There is a technical reason that I'll go into now (but you can skip if you want). The Intranet is hosted on a Windows server because much of the content is written in the ASP programming language. This cannot be run from a Linux machine. The SDS and Moodle are hosted on Linux machines, but the SDS must be run from a different server for security reasons. So, you must log into all three because all three are on different servers.

I find that the language used in the menus/pages isn't always very friendly for the user, whether that is parents, students, or faculty. It may make sense to the technical people, but not be relevant/appropriate for how we would commonly talk about it (e.g. canned reports, generate vs. output reports

Because the sidebar is narrow, we must come up with short but memorable names for the different pages in the SDS. Each page must also be named differently due to technical restraints in the SDS. As such, we have to come up with a variety of (sometimes crazy) names for each section. There are so many different types of reports (report cards, canned reports, generated reports, etc.), for example, that we have started to run out of descriptive names.

If you have suggestions for short names that are more descriptive, please let us know by emailing sdshelp@smus.ca.

Procedural Changes

We have implemented a couple of procedural changes/clarifications as a result of comments from the survey and discussions about those comments with the technology committee.

Maintenance Window

In order to make SDS outages more predictable, we will perform routine maintenance on Fridays from 4:15 pm - 5:00 pm. This includes putting new SDS versions that require data migrations live, applying updates to servers running the SDS, and anything else that could result in the SDS being unavailable. The SDS could be unavailable for any portion of that maintenance window each week. Not all updates take 45 minutes, and we do not need to apply maintenance every week, so the SDS may still be available during the maintenance window.

If maintenance will be performed outside of the maintenance window, we will communicate the outage time and estimated duration at least 48 hours before the event. If the window creates critical timing conflicts, please let us know at least 24 hours before the outage starts so that we can reschedule it.

Emergency maintenance will continue to be applied whenever it is necessary. We try to keep the number of occurrences of emergency maintenance to a minimum. Any emergency maintenance will be accompanied with an email to all faculty and staff, so check your email if you are unable to access the SDS outside of the maintenance window.

If the SDS is unavailable and think you should be able to access it, please email sdshelp@smus.ca.

Overriding Request Prioritization

If you have submitted a request and it has been rejected, has been assigned a priority that you think is too low, or has been inactive for too long, we now have an avenue to request a priority override. Please send requests through your department head or manager to Rob Przybylski, who has the final say (after consulting with his superiors if necessary) in prioritizing SDS requests.

Retrieved from "https://wiki.smus.ca/index.php?title=SDSHOWTO:Survey_2011_Responses&oldid=5746"