A few weeks back I was pretty excited because one of our high school language classes used our "new" Linux lab (not really new as the computers are circa 2002, but this is our first year using Ubuntu Linux in a lab)-this was the first time that we had an entire class of students using this space! But I was even more excited about an idea that we stumbled upon. The students were using the lab to do one of their weekly writing samples in their Spanish language class with their teacher, Carolina Morouder. Typically speaking the students used MS Word and then printed their paragraph at the end of class as a way to hand in their work. Because our linux lab is not connected to printers, we had the students start a google document and then quickly share that document with Carolina. As a result of the work being shared with her, there was no need for the students to print. Using google docs, Carolina was able to leave feedback on each student's work. I started to think about what would happen if each time every student in this class shared a google document with Carolina as a way to turn in a writing sample for feedback. Then I started thinking about how Carolina has several classes. This would result in a fair amount of chaos in her google documents space. In order to solve this problem, we decided for the next writing sample that these students would work in the same document that they already shared-this would alleviate the need for the students to share a document once again and it would prevent Carolina's google document workspace from filling up with several short documents from each student. The next time the students work on their writing sample they would open the same document that they already shared, set their cursor in at the top of the document, enter down a few times to create some space (and maybe even insert a horizontal rule), and then start writing at the top of the document. Over time, this document would become chronologically ordered with the most recent writing samples at the top of the document.
Finally, as time goes along, students may organize their single writing sample with a table of contents and the bookmarks feature in google docs (this feature is AWESOME).
I published a sample of what this could look like in a google docment by taking three posts from this blog and pasting them in a google document. I added a table of contents and bookmarks and here is what it looks like.
Just as a side note, I don't believe Carolina has carried on with this method (which is totally OK!) I was happy that she tried this, however, because it lead to a pretty excellent strategy for information organization and management.
Finally, I think this fits in with student ePortfolios so very nicely. Imagine at the end of the semester/school year if the students made a copy of their google doc writing samples in Spanish class, and then selected a handful of items that they wanted to place in their ePortfolio. Great possibilities here!
Thoughts and reflections on the world of educational technology...oh, and a few other things
Showing posts with label Google Apps. Show all posts
Showing posts with label Google Apps. Show all posts
Friday, October 09, 2009
Sunday, October 04, 2009
Google Apps for Education - Rating Our Transition - The Mistakes
So in a previous post I shared what went well with our transition to Google Apps for Education from Firstclass. I would say that we did many, many things well, but we did make some mistakes. In the spirit of openness, transparency, and a hope that someone out there will learn from our mistakes, let me elaborate on where we failed here in this post.
Some data about our transition (may be helpful to compare to your transition for scale):
Number of accounts transitioned from Firstclass to Google: 550
Number of faculty/staff accounts: about 125
Number of student accounts: about 425
Years our school had used Firstclass: I believe around 10
1. We made promises we couldn't keep - Particularly in the area of Firstclass conference replication and data migration. Firstclass has this tool called "Conferences" that some of our users really liked. Prior to the transition we told people that Google Sites along with mail groups would give them the same functionality. The truth is that Google Sites doesn't do the same exact thing that Firstclass conferences, yet we promised folks that they would. Secondly, we promised that all data would migrate over, including calendars, contacts, and mail. We made a big mistake here. Firstclass is so horribly broken in terms of IMAP and other systems standards that it simply wasn't possible to automatically migrate sub-folder mail content from firstclass with the push of a button. In retrospect we should've tested data migration more thoroughly prior to announcing that mail content would be migrated over from the old system to the new. Don't make promises you can't keep if you are heading in this direction.
2. DNS Preparation - we were ill prepared with new DNS entries up and ready to go for all of our new services. There were a few times after our cut date where our new mail address wasn't working internally...as a matter of act, it still isn't working, but thanks to Adam Contois we have some hack in place that does a quick re-direct internally.
3. Calendaring confusion - I can't say this is a mistake because we truly didn't anticipate that our entire organizational calendaring system would move over to Google Apps Calendar. Firstclass' calendaring is fairly wretched and we were using FinalSite's calendaring system which we purchased as a part of their web CMS. I don't think anyone who managed our calendars was particularly satisfied with Finalsite as the calendaring solution, so when Google Calendar came around we had some folks who were eager to try it out. Calendaring seems to be a real challenge in most organizations, and when we moved to Google Cal we didn't quite have our arms around how we were going to implement this as our organizational calendaring system. Luckily we had several folks step up (Mid, Dana, Katherine, Shannon) to build an excellent solution for our calendaring needs-they created an entire Google Site in our network that has all of the various calendars that our folks may elect to subscribe to.
We also have had some difficulties with the use of using Google Calendar for scheduling some of our resources like computer labs and rooms. We're still trying to figure this out at the time of this post and if we arrive to a solution I will share it out here.
4. Document Sharing - we didn't expect so many of our folks to use google docs to share information, which is absolutely great! However, many people are using Google Docs instead of sending attachments or placing the message right in the body. This is causing a bit of "Google Doc" fatigue. Google docs are great for collaborative writing, but when it comes to simply passing along information that you'd like people to read, attaching a document or placing the text in the body of the email is completely fine (or simply publishing the doc to a URL and sharing that URL is another good route). I'm going to create a little help document that helps people decide when they might consider sharing a google doc vs. sending a standard attachment. This isn't a huge deal, but some of our folks are experiencing a little Google Docs fatigue.
5. Network mail groups - we have way too many network mail groups. We have nearly 60 or so that we brought over from firstclass. We should've probably thinned this list down to a few dozen or so when we transitioned, but it proved easier said than done. I'd imagine as time progresses we'll only keep the highly useful ones around.
6. Client software for mail access - prior to the transition we talked to our folks about how they could use various mail clients like Mac Mail, Thunderbird, Outlook, etc. It is true that this is possible, but as a school tech department it is difficult to support all these various client software programs. We now have a policy that we only support web access to email...folks are welcome to configure a client, but they are pretty much on their own if they go this route.
7. Mobile support - we should've been clearer about how we were going to support mobile access. Outside of providing links to help documents and video tutorials that show users how to configure their iPhones, Blackberries, etc, we really don't have the bandwidth to support all of these various mobile platforms that are represented in our student, faculty and staff community. Luckily mobile access setup of Google mail is really easy, so we really haven't had to offer a great deal of high touch support for mobiles.
8. Under-estimation of support during for the transition - While we did have a transition support team of 8 faculty and staff or so, looking back it would've been best had we doubled that number with an appointed transition expert in each department. I'm a big believer in empowering community members to help each other out and our transition team went part of the way in making this happen.
Some data about our transition (may be helpful to compare to your transition for scale):
Number of accounts transitioned from Firstclass to Google: 550
Number of faculty/staff accounts: about 125
Number of student accounts: about 425
Years our school had used Firstclass: I believe around 10
1. We made promises we couldn't keep - Particularly in the area of Firstclass conference replication and data migration. Firstclass has this tool called "Conferences" that some of our users really liked. Prior to the transition we told people that Google Sites along with mail groups would give them the same functionality. The truth is that Google Sites doesn't do the same exact thing that Firstclass conferences, yet we promised folks that they would. Secondly, we promised that all data would migrate over, including calendars, contacts, and mail. We made a big mistake here. Firstclass is so horribly broken in terms of IMAP and other systems standards that it simply wasn't possible to automatically migrate sub-folder mail content from firstclass with the push of a button. In retrospect we should've tested data migration more thoroughly prior to announcing that mail content would be migrated over from the old system to the new. Don't make promises you can't keep if you are heading in this direction.
2. DNS Preparation - we were ill prepared with new DNS entries up and ready to go for all of our new services. There were a few times after our cut date where our new mail address wasn't working internally...as a matter of act, it still isn't working, but thanks to Adam Contois we have some hack in place that does a quick re-direct internally.
3. Calendaring confusion - I can't say this is a mistake because we truly didn't anticipate that our entire organizational calendaring system would move over to Google Apps Calendar. Firstclass' calendaring is fairly wretched and we were using FinalSite's calendaring system which we purchased as a part of their web CMS. I don't think anyone who managed our calendars was particularly satisfied with Finalsite as the calendaring solution, so when Google Calendar came around we had some folks who were eager to try it out. Calendaring seems to be a real challenge in most organizations, and when we moved to Google Cal we didn't quite have our arms around how we were going to implement this as our organizational calendaring system. Luckily we had several folks step up (Mid, Dana, Katherine, Shannon) to build an excellent solution for our calendaring needs-they created an entire Google Site in our network that has all of the various calendars that our folks may elect to subscribe to.
We also have had some difficulties with the use of using Google Calendar for scheduling some of our resources like computer labs and rooms. We're still trying to figure this out at the time of this post and if we arrive to a solution I will share it out here.
4. Document Sharing - we didn't expect so many of our folks to use google docs to share information, which is absolutely great! However, many people are using Google Docs instead of sending attachments or placing the message right in the body. This is causing a bit of "Google Doc" fatigue. Google docs are great for collaborative writing, but when it comes to simply passing along information that you'd like people to read, attaching a document or placing the text in the body of the email is completely fine (or simply publishing the doc to a URL and sharing that URL is another good route). I'm going to create a little help document that helps people decide when they might consider sharing a google doc vs. sending a standard attachment. This isn't a huge deal, but some of our folks are experiencing a little Google Docs fatigue.
5. Network mail groups - we have way too many network mail groups. We have nearly 60 or so that we brought over from firstclass. We should've probably thinned this list down to a few dozen or so when we transitioned, but it proved easier said than done. I'd imagine as time progresses we'll only keep the highly useful ones around.
6. Client software for mail access - prior to the transition we talked to our folks about how they could use various mail clients like Mac Mail, Thunderbird, Outlook, etc. It is true that this is possible, but as a school tech department it is difficult to support all these various client software programs. We now have a policy that we only support web access to email...folks are welcome to configure a client, but they are pretty much on their own if they go this route.
7. Mobile support - we should've been clearer about how we were going to support mobile access. Outside of providing links to help documents and video tutorials that show users how to configure their iPhones, Blackberries, etc, we really don't have the bandwidth to support all of these various mobile platforms that are represented in our student, faculty and staff community. Luckily mobile access setup of Google mail is really easy, so we really haven't had to offer a great deal of high touch support for mobiles.
8. Under-estimation of support during for the transition - While we did have a transition support team of 8 faculty and staff or so, looking back it would've been best had we doubled that number with an appointed transition expert in each department. I'm a big believer in empowering community members to help each other out and our transition team went part of the way in making this happen.
Google Apps for Education - Rating Our Transition - The Good
Well, it has been almost 4 full months since my school fully transitioned away from the Firstclass email system to the Google Apps for Education suite. In a series of posts over the next few weeks I'm going to share what we did well and what we wish we could do over. Today I'm going to start with what we did well during our transition (not to gloat, but we did do many things well, hence the ridiculously long post). As a side, I want to say that I'm incredibly impressed by how our users are making use of this network so far. We have some faculty and staff members piloting the use of ePortfolios with Google Sites and many other wonderful things going on as well. For seven years I worked at a school that used Microsoft Exchange and last year I used Firstclass at Castilleja. Without any hesitation, I can say that Google Apps smokes both of these platforms in terms of easy of use and collaboration potential (note how I didn't even mention anything about Google Apps being free and these other platforms costing a serious amount of money in terms of annual licensing, hardware, and IT staffing/management ;-)
Things we did well in our move to Google Apps for Education:
1. Youth helpers - We solicited the assistance of our students before, during, and after our June 15th, 2009 cut date and they were a tremendous help. In April we asked interested high school students to serve as "early adopters" of the new system. A handful agreed to transition to the system early and their participation was key. Some of these students even configured their mobile devices to access mail which they really appreciated. These early adopters gave us feedback and helped us tune and further customize our support materials that would be critical during the larger roll out.
We also had one of our student summer tech department interns create a series of screencasts to help support students throughout the transition. Ultimately these screencasts turned out to be more helpful to our faculty and staff members. Screencasts in general have been of immense value in getting the word out and providing support materials to our users.
2. Faculty and Staff Early Adopters - In addition to asking students to be early adopters, we also asked our faculty and staff to join in as early adopters last April and May. Once again, having these early adopters in the new space and providing feedback to us turned out to be immensely valuable on many different levels. We created weekly "Early Adopter Newsletters" for the 20 or so early adopters. This newsletter series helped keep people updated on our progress with the overall transition.
3. Transition Support Site - We created a transition support site that served as a repository for our support docs, tutorials, screencasts, etc. I'm not sure how many people used this site, but to this day is has served as a nice little portfolio of our transition. I'm glad we "ate our own dogfood" and used a Google Site to manage and organize these support members. Dave Girouard, who manages Google's Enterprise business worldwide, actually commented on our transition site in this Twitter post.
4. Faculty and Staff Transition Support Team - We created a support team of roughly 8 faculty and staff members who helped in many ways with our transition. In addition to creating support tutorials and attending a few meetings to help prepare the community for the move, they also contributed to a series of workshops we offered for our school community in late August. I greatly appreciate the hard work and contributions of all who participated on this team.
5. Workshops - Speaking of workshops, these turned out to be incredibly helpful for many of our staff and faculty members. We offered one on June 16th and three in late August. We basically went through each component of the network (mail, sites, calendar, doc sharing) in these workshops. They were each about 2 hours in length and participants were quite appreciative of these learning opportunities.
6. Faculty and Staff Dashboard Start Page - Thanks to the outstanding work of our Director of Technology, Steve Taffee, we have an awesome faculty and staff start page/dashboard. Google Apps networks certainly can be a bit messy when you first start out, and having folks set something like this as their home page can really simply information access for your folks. Here is a screenshot of what ours looks like (this dashboard was created with google sites and is permissioned to be visible only by users who have authenticated to the network). We created a dashboard start page for students too, but so far most of them don't really use it.
7. Activating most/all of the services - We activated pretty much all of the services for our student, staff and faculty users. This includes mail, sites, docs, contacts and contact sharing, mobile/cell phone access, calendar, and chat. We enabled other services including a custom URL generator (kinda like tinyurl) and Google's Moderator platform as well, but for some reason we can't configure our DNS internally to get these tools to work inside of the school's LAN. We also checked an option in the control panel that allows new labs and features to be available to users in our network. This gives our faculty, staff and students access to an ever evolving, powerful set of applications that allow them to collaborate, share and communicate in ways we couldn't have imagined even a few years ago. Our users love the gmail themes and labs. It is my belief that if you make powerful tools available to people and expect that they will do creative and powerful things, they will rise to the occasion (alternately, if you lock things down because you're afraid users might do something bad, they will engage you in an unending cat and mouse game that you cannot win). I'm glad to be at a school where we have liberal user policies that demonstrate trust and faith in our community members.
8. Custom login page - This was created by the handy work of our system engineer, Adam Contois (no, you can't hire him--in addition to his excellent work with python and the custom apps he has built for our google network, he is needed to push mobile lab carts around our campus ;-) You may view our login page here. Along with providing a school branded login point to these services, Adam also configured this application to allow administrators to sign in as other users (I believe this was all managed and configured with the Google OAUTH API). Being able to sign in as other users to help support is absoultely INVALUABLE. We did have Adam join us on the Edtech Brainstorm at Edtechtalk.com in June of 2009 to talk a little bit about some of the cool customizations he built for our network. Listen to the recorded audio from this conversation online here. Adam likes a good challenge and his work with our Google network and the other academic learning systems that we have in place (Linux lab, Moodle, Open Source client software deployment, etc) is greatly appreciated!
9. Research and development - We worked extremely hard on R and D with this network all of last year. Last year we activated the docs sharing component of the network and the students and teachers who used this really liked it (especially for things like collaborative scripts for movies, podcasts, etc). A year of using the network for document collaboration only really helped us learn the ins and outs of the system. We also spent time researching integration with Moodle and building our custom login page and experiementing with OAUTH. We dabbled with LDAP user directory integration, but at the end of the day we deciced not to enable this as our LDAP system wasn't in the best shape. Speaking of Moodle and Google, we were pretty psyched about the possibility for using this, but at the end of the day we decided not to go this route because we didn't want our non-teaching staff members to access their mail by going through Moodle. We also didn't want a scenario where access to mail became dependent on our Moodle network...we figured that Google's uptime would be better than our own Moodle network. But we still do think it is pretty cool that users could authenticate into moodle and then easily access the Google network from the google apps block in Moodle.
10. Development of a "pilot google apps network." In order to do much of the aforementioned R&D, we setup a "pilot" Google Apps network (the domain was "pilot.castilleja.org.") This allowed us a sandbox space to test, evaluate, play, explore, destroy, and discover new things. Google allows you to do this free of charge and I recommend to any organization who might be transitioning to Google to deploy a pilot network.
11. Networking and sharing - We spoke with people all over the place via telephone, social networks, etc. We linked up with several other independent schools who were thinking about transitioning away from Firstclass to Google Apps and we shared ideas in an online forum. We even hosted a webcast at one point to discuss strategies. We spoke with the lead IT manager at UW-Madison's Alumni network. UW-Madison had just shifted their mail services away from some proprietary application to Gmail and his advice and sharing of experiences was very helpful (I can't find his name, but when I do I will update this post).
12. Conference calls with our transition support reps from Google Education, Cindy and Austin, were extremely helpful as well. Google gives away transition support for free...this basically means that they dedicate a representative who is available via email, phone, google voice, etc up until you flip the switch and actually transition. They were extremely helpful in providing us with documents and suggestions to help ensure a smooth transition. We had basic questions regarding data ownership, reliability, data mining, advertising, security, etc-before we got too far along in the process we had answers to these questions-it is important that you do the same because people in your organization who are skeptical about outsourcing email will ask these questions and may event try to to spread FUD (Fear, Uncertainty and Doubt). We aggregated much of the documentation and answers to our questions from google early in this process over at this wiki.
13. Installation of a Moodle virtual learning network to work in tandem with Google Apps. We installed Moodle at the beginning of the 2008-2009 network for faculty members who want a true virtual instructional environment that allows for assignment submission and grading. I mentioned above that we decided against the full google-moodle integration, but even having Moodle available for our teachers to use has been great.
14. Enabling of Postini Spam Services - Right now google is giving away Postini spam services free of charge. When we switched to Gmail we did see a fair amount of spam slipping through Google's basic spam service. After enabling Postini, this ended.
15. Student user name method -We used the last two digits of student graduation years + first initial + last name for student user names in the network. This means that Sara Smith from the class of 2020 would have a username of 20ssmith. This has made it really easy for administration, searching for students in the network, building contact lists, handling conflicts with users having the same name, etc.
16. Enabling mobile access for all users - I mentioned that we enabled almost all possible services above, but mobile services have been great thus far. Many of our users, including students, are configuring their various mobile devices to access their information in the network.
17. Transparency - We were transparent from the very beginning when we were floating the idea about possibly switching from Firstclass. We talked about this at committee meetings, with student groups, and we gave separate presentations at our all-faculty and all-staff meetings last spring. Our Transition Support site was, from the first day, made available on the open web and wasn't closed in any way. Throughout the process we solicited suggestions and feedback. By the time the final decision was made by our administrative leadership team, we had the support of the overwhelming majority of our school community. We even recorded our proposal presentation to our faculty and posted it for those who couldn't be in attendance. I feel as though by being direct and transparent we were able to build some positive mojo for this move.
Things we did well in our move to Google Apps for Education:
1. Youth helpers - We solicited the assistance of our students before, during, and after our June 15th, 2009 cut date and they were a tremendous help. In April we asked interested high school students to serve as "early adopters" of the new system. A handful agreed to transition to the system early and their participation was key. Some of these students even configured their mobile devices to access mail which they really appreciated. These early adopters gave us feedback and helped us tune and further customize our support materials that would be critical during the larger roll out.
We also had one of our student summer tech department interns create a series of screencasts to help support students throughout the transition. Ultimately these screencasts turned out to be more helpful to our faculty and staff members. Screencasts in general have been of immense value in getting the word out and providing support materials to our users.
2. Faculty and Staff Early Adopters - In addition to asking students to be early adopters, we also asked our faculty and staff to join in as early adopters last April and May. Once again, having these early adopters in the new space and providing feedback to us turned out to be immensely valuable on many different levels. We created weekly "Early Adopter Newsletters" for the 20 or so early adopters. This newsletter series helped keep people updated on our progress with the overall transition.
3. Transition Support Site - We created a transition support site that served as a repository for our support docs, tutorials, screencasts, etc. I'm not sure how many people used this site, but to this day is has served as a nice little portfolio of our transition. I'm glad we "ate our own dogfood" and used a Google Site to manage and organize these support members. Dave Girouard, who manages Google's Enterprise business worldwide, actually commented on our transition site in this Twitter post.
4. Faculty and Staff Transition Support Team - We created a support team of roughly 8 faculty and staff members who helped in many ways with our transition. In addition to creating support tutorials and attending a few meetings to help prepare the community for the move, they also contributed to a series of workshops we offered for our school community in late August. I greatly appreciate the hard work and contributions of all who participated on this team.
5. Workshops - Speaking of workshops, these turned out to be incredibly helpful for many of our staff and faculty members. We offered one on June 16th and three in late August. We basically went through each component of the network (mail, sites, calendar, doc sharing) in these workshops. They were each about 2 hours in length and participants were quite appreciative of these learning opportunities.
6. Faculty and Staff Dashboard Start Page - Thanks to the outstanding work of our Director of Technology, Steve Taffee, we have an awesome faculty and staff start page/dashboard. Google Apps networks certainly can be a bit messy when you first start out, and having folks set something like this as their home page can really simply information access for your folks. Here is a screenshot of what ours looks like (this dashboard was created with google sites and is permissioned to be visible only by users who have authenticated to the network). We created a dashboard start page for students too, but so far most of them don't really use it.
7. Activating most/all of the services - We activated pretty much all of the services for our student, staff and faculty users. This includes mail, sites, docs, contacts and contact sharing, mobile/cell phone access, calendar, and chat. We enabled other services including a custom URL generator (kinda like tinyurl) and Google's Moderator platform as well, but for some reason we can't configure our DNS internally to get these tools to work inside of the school's LAN. We also checked an option in the control panel that allows new labs and features to be available to users in our network. This gives our faculty, staff and students access to an ever evolving, powerful set of applications that allow them to collaborate, share and communicate in ways we couldn't have imagined even a few years ago. Our users love the gmail themes and labs. It is my belief that if you make powerful tools available to people and expect that they will do creative and powerful things, they will rise to the occasion (alternately, if you lock things down because you're afraid users might do something bad, they will engage you in an unending cat and mouse game that you cannot win). I'm glad to be at a school where we have liberal user policies that demonstrate trust and faith in our community members.
8. Custom login page - This was created by the handy work of our system engineer, Adam Contois (no, you can't hire him--in addition to his excellent work with python and the custom apps he has built for our google network, he is needed to push mobile lab carts around our campus ;-) You may view our login page here. Along with providing a school branded login point to these services, Adam also configured this application to allow administrators to sign in as other users (I believe this was all managed and configured with the Google OAUTH API). Being able to sign in as other users to help support is absoultely INVALUABLE. We did have Adam join us on the Edtech Brainstorm at Edtechtalk.com in June of 2009 to talk a little bit about some of the cool customizations he built for our network. Listen to the recorded audio from this conversation online here. Adam likes a good challenge and his work with our Google network and the other academic learning systems that we have in place (Linux lab, Moodle, Open Source client software deployment, etc) is greatly appreciated!
9. Research and development - We worked extremely hard on R and D with this network all of last year. Last year we activated the docs sharing component of the network and the students and teachers who used this really liked it (especially for things like collaborative scripts for movies, podcasts, etc). A year of using the network for document collaboration only really helped us learn the ins and outs of the system. We also spent time researching integration with Moodle and building our custom login page and experiementing with OAUTH. We dabbled with LDAP user directory integration, but at the end of the day we deciced not to enable this as our LDAP system wasn't in the best shape. Speaking of Moodle and Google, we were pretty psyched about the possibility for using this, but at the end of the day we decided not to go this route because we didn't want our non-teaching staff members to access their mail by going through Moodle. We also didn't want a scenario where access to mail became dependent on our Moodle network...we figured that Google's uptime would be better than our own Moodle network. But we still do think it is pretty cool that users could authenticate into moodle and then easily access the Google network from the google apps block in Moodle.
10. Development of a "pilot google apps network." In order to do much of the aforementioned R&D, we setup a "pilot" Google Apps network (the domain was "pilot.castilleja.org.") This allowed us a sandbox space to test, evaluate, play, explore, destroy, and discover new things. Google allows you to do this free of charge and I recommend to any organization who might be transitioning to Google to deploy a pilot network.
11. Networking and sharing - We spoke with people all over the place via telephone, social networks, etc. We linked up with several other independent schools who were thinking about transitioning away from Firstclass to Google Apps and we shared ideas in an online forum. We even hosted a webcast at one point to discuss strategies. We spoke with the lead IT manager at UW-Madison's Alumni network. UW-Madison had just shifted their mail services away from some proprietary application to Gmail and his advice and sharing of experiences was very helpful (I can't find his name, but when I do I will update this post).
12. Conference calls with our transition support reps from Google Education, Cindy and Austin, were extremely helpful as well. Google gives away transition support for free...this basically means that they dedicate a representative who is available via email, phone, google voice, etc up until you flip the switch and actually transition. They were extremely helpful in providing us with documents and suggestions to help ensure a smooth transition. We had basic questions regarding data ownership, reliability, data mining, advertising, security, etc-before we got too far along in the process we had answers to these questions-it is important that you do the same because people in your organization who are skeptical about outsourcing email will ask these questions and may event try to to spread FUD (Fear, Uncertainty and Doubt). We aggregated much of the documentation and answers to our questions from google early in this process over at this wiki.
13. Installation of a Moodle virtual learning network to work in tandem with Google Apps. We installed Moodle at the beginning of the 2008-2009 network for faculty members who want a true virtual instructional environment that allows for assignment submission and grading. I mentioned above that we decided against the full google-moodle integration, but even having Moodle available for our teachers to use has been great.
14. Enabling of Postini Spam Services - Right now google is giving away Postini spam services free of charge. When we switched to Gmail we did see a fair amount of spam slipping through Google's basic spam service. After enabling Postini, this ended.
15. Student user name method -We used the last two digits of student graduation years + first initial + last name for student user names in the network. This means that Sara Smith from the class of 2020 would have a username of 20ssmith. This has made it really easy for administration, searching for students in the network, building contact lists, handling conflicts with users having the same name, etc.
16. Enabling mobile access for all users - I mentioned that we enabled almost all possible services above, but mobile services have been great thus far. Many of our users, including students, are configuring their various mobile devices to access their information in the network.
17. Transparency - We were transparent from the very beginning when we were floating the idea about possibly switching from Firstclass. We talked about this at committee meetings, with student groups, and we gave separate presentations at our all-faculty and all-staff meetings last spring. Our Transition Support site was, from the first day, made available on the open web and wasn't closed in any way. Throughout the process we solicited suggestions and feedback. By the time the final decision was made by our administrative leadership team, we had the support of the overwhelming majority of our school community. We even recorded our proposal presentation to our faculty and posted it for those who couldn't be in attendance. I feel as though by being direct and transparent we were able to build some positive mojo for this move.
Subscribe to:
Posts (Atom)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7cd09b01-05f3-42c3-a694-ce3be6111d26)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=b95fdfd6-442c-4408-a8aa-cb456b028f98)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=50540fe2-8393-4195-8c1c-cdb0bb8450f1)