Cal Alumni Network
1 like546 views
The document discusses the strategies for building an alumni network at the University of California, Berkeley, emphasizing business, integration, and building strategies. It covers the importance of user data, the development of an in-house platform to improve user experience, and the implementation of a responsive design approach. Additionally, it highlights challenges faced in adapting existing sites and the benefits of a single codebase for mobile and desktop versions.
Cal Alumni Network
- 1. Building an Alumni Network with a small team, a clear strategy, and lots of chutzpah Berkeley UNIVERSITY OF CALIFORNIA JOEL FULLER, JASON STROYER, CHRISTINA SPONSELLI MARKETING & COMMUNICATIONS 1 -Title of presentation -Introduction of speakers -Acknowledge other members of the team, Matt, Rob, Virginia, David. Customer service team at the Cal Alumni Association
- 2. What we’ll discuss Business Strategy Integration Strategy Building Strategy 2 -Describe @cal project -Outline of presentation is in three sections -Questions after each section
- 3. Business Strategy 3
- 4. Business Strategy 4 Launch in August, still soft launch, mailing out postcards next mnth
- 5. Business Strategy 77% of alums who have visited the site have updated their data 5 Its about the data
- 6. Business Strategy 6
- 7. Business Strategy 7
- 8. Business Strategy 8 1. Exercise to identify actual relationship and ideal experience 2. Map service used by an alum during life cycle
- 9. Business Strategy Core competencies Email forwarding Alumni directory Networking opportunities 9
- 10. Business Strategy Build in-house? Team with skills Need for a nimble platform Bad experiences with vendors Greater control over environment 10 Also include mobilization
- 11. Business Strategy But there are complexities... Logins Alum’s data Domain names Alums’ expectations 11 Describe points Reference single sign-on, which Jason will describe later
- 12. Business Strategy Exit Strategy Assess functionality Determine technical requirements Alumni directory Review contract 12 - Didnʼt bring all functionality over because wasnʼt being used by alums. But saw opportunity to create public profiles, will speak more about it next slide. - Tech reqs: Did not change the user experience, but we upgraded servers to LAMP stacks. Cost was low for us, but we couldn't offer the bandwidth of this new site without new virtual servers. - Review terms of contract, including when notice must be given, process for destroying data, and requesting data be pulled for new site. -look for opportunities!!
- 13. Business Strategy 13
- 14. Business Strategy 14 Creating @cal public profile. About 40% of people who have logged into the network since August have created a public profile. 1. Help people find our alums and their social media profile 2. Offer a university-related URL for the page 3.Allow alums to customer their URL & page 4. Make it searchable by commercial search engines
- 15. Business Strategy 15 This alum is a 1979 grad 1. May choose from images we provide 2. Allow people to contact page owner anonymously 3. Alums may update information in real-time
- 16. Business Strategy 16
- 17. Business Strategy Questions 17
- 18. Integration Strategy 18
- 19. Integration Strategy Single sign-on 19 CS: Before making the move off our vendor, we were fortunate enough to have taken control of system of logging into our alumni network. Jason Stroyer, the projectʼs programmer, will talk more about single sign on and how we worked with other campus groups. JS: Here you can see the login screen (left) and the same screen with the Help section opened up.
- 20. Integration Strategy The passphrase reminder is the seventh most visited page on the site The login name reminder is number nine 20 JS: Talk about the reminders. Why were they necessary? How do they work?
- 21. Integration Strategy Migration of Users to Single Sign-On email with token no no 5. friendly 4. CalNet login name yes yes successful yes drupal site Instructional with text about customization no process no start point for no users not 1. coming Confirm Your Secret through an Identity question continued to email process screen 6 starts customer service area verified no 1. Confirm Your Identity yes no start point for users 2. authenticated Change Your by customer Passphrase service 6. form data Customer 1. Confirm emailed to service will Your Identity customer contact you continued to service within two next page business days. Documents/@cal/flows/emails_080124 Page 1 of 2 Notes Revised Jan. 24 1. Shaded box indicates CalNet screen with very little C. Sponselli customization. change password screen customer service area change successful no password yes no 3. Update to a personalized CalNet ID 6. form data Customer change emailed to service will password customer contact you service within two business days. 5. 5. update to CalNet login CalNet login friendly yes successful no with with customization customization no yes no drupal site form data 6. Secret emailed to Customer service Documents/@cal/flows/emails_080124 question customer will contact you Page 2 of 2 process service within two Revised Jan. 24 starts business days. C. Sponselli 21 JS: Donʼt know if you want to use this. We can easily delete before presentation.
- 22. Integration Strategy Email with CAS CAS login authentication info Notes: 1. Details on CAS authentication available Data synchronization on Authentication with CAS 2. ----- represents data synch 3. ___ represents end user experience Documents/@cal/flows/big_pic_architecture_nuser Disclaimer: 8 October 2007 1. Flow doesn't include LDAP process C. Sponselli Community Architecture, New Users Via Customer Service Creation of Customer Email or phone new CADS Service looks call to end user record based CADS up info on giving CAS on end user login info CADS request Convio PCI Affinity Circles/Haas Post-login for Convio PCI Affinity all units Circles End user authenticates on CAS 22 JS: Here is an example of our data synchronization before we built the network in-house. The architecture has changed, but this gives you a sense of the complexity of working with data. - Didnʼt want this to lose this data to commercial social media sites and updates stream, too. - Data updates are being made in @cal by users, and can't be overwritten by alumni database updates. Alums are records of source. We don't want to overwrite. - Build admin tools to update site for end users. - When build new site, created tools to compensate for pain points experience working with vendors. We made it more transparent. Information we weren't getting about errors, emails are triggered and we can respond to them. We built into place admin tools. - Taking on data synchronization formatting. Matching the vendor format to streamline import process. Alumni information management staff didn't need to make modifications to their existing work. We looked to vendor documents and replicated it so they wouldn't need to change the nightly processes. - We are synchronizing because their additional fields that the alumni databased doesn't
- 23. Integration Strategy Email forwarding 23 One of our core competencies is email forwarding. - Explain what email forwarding is. Allow current students to convert their student email address, and for alums they can select jason@engineeralum.berkeley.edu. - Discuss how email addresses are displayed and give examples of affinity based assignments, schools/colleges/alumni association - One of the top reasons people join @cal. - For some alums, only register to get this service
- 24. Integration Strategy Questions 24
- 25. Building Strategy 25
- 26. Building Strategy Working in HTML Form followed function • Initial functionality implemented without design. • Wireframes introduced to add structure for improving UX and testing feedback early in the process. Functional wireframes 26 Working through the wireframe into design. Working in HTML allowed us to get UI testing early on and were able prove the concept sooner in the process. Style was intentionally left out initially. We were able to determine how close we were to our core concepts without the worry of style. This also allowed us to be more agile in development of functionality early on as we had working prototypes to gain feedback.
- 27. Building Strategy Working in HTML Form followed function • Determined mobile approach mid-way through. • Once functionality was refined, design and styling furthered UI improvements. • We continue to iterate and improve the UI and UX. 27
- 28. Building Strategy User Testing Leveraging on-campus resources and partnerships • “Break our code” night. Never underestimate pizza! 28 Christina to discuss user testing and break our code night
- 30. Building Strategy Mobile development Overview • What is Responsive Web Design? • Why did we choose responsive? The @cal mobile approach. Benefits and drawbacks of responsive design. • Mobile first and deciding selective features. 30
- 31. Building Strategy What is responsive design? Developing a website that “responds” to devices based on specific screen sizes (break points). http://mediaqueri.es/ Single most important development question is: • What are your user's mobile priorities? 31
- 32. Building Strategy What is responsive design? Developing a website that “responds” to devices based on specific screen sizes (break points). Demonstrate @cal RWD Oski Profile Oski Search http://mediaqueri.es/ Single most important development question is: • What are your user's mobile priorities? 32
- 33. Building Strategy Why did we choose responsive? The @cal approach • Restricting break points to mobile and desktop. Skipped initially Mobile Tablet Desktop 33
- 34. Building Strategy Why did we choose responsive? The @cal approach • Below the mobile break point uses fluid layout, accommodating many devices, casting a “wide net.” Mobile Tablet 34 Limiting to the technique of having a fluid design below the breakpoint. Easing the development workload by casting a wide net when possible.
- 35. Building Strategy Why did we choose responsive? The @cal approach • Below the mobile break point uses fluid layout, accommodating many devices, casting a “wide net.” 35
- 36. Building Strategy Why did we choose responsive? We looked at other mobile options • Separate mobile site using a mobile framework, or specialized “site” optimized for mobile. • Separate mobile sites can be good for specialized content which does not translate well to RWD, such as a web application. 36
- 37. Building Strategy Why did we choose responsive? Benefits • One is more than two. Maintaining one codebase. Avoid coding, styling and maintaining two separate websites. • Can be a much faster development time/testing cycle. • Further CSS development from front-end developer. • No need for additional backend programming or new codebase. • Track analytics on one domain. Users interact with one website on various devices. 37 In this case, one truly is more than two.
- 38. Building Strategy Why did we choose responsive? What are “best-use” RWD scenarios? • Project with limited developer resources or budget for mobilizing. • Site that does not have too many image elements (content images) or photo galleries. • Site that is not overly complex in CSS/design. • Site that can naturally "reflow" fairly well using CSS floating techniques as opposed to positioning techniques. 38
- 39. Building Strategy Why did we choose responsive? What are “challenging” RWD scenarios? • Adapting an existing site that uses a content managing system such as WordPress or Drupal with legacy content. Themes are available for both CMS’. • A site with highly complex detailed content such as a news portal, albeit this is possible with the right developer experience and markup planning. • A site with many image elements or large images such as photo galleries, etc. 39 unless you have thorough template experience.
- 40. Building Strategy Mobile First and selected features A mobile first approach • Plan for feature set you want to provide for mobile users first. This will help establish your required priorities and site structure (markup). Features • Decide what you will or can offer users of your site. Do they need that picture gallery? Is the contact information paramount? Look at current site’s metrics to help you determine site use. Maybe they don’t need to upload files or pictures. • What must they be able to do? 40 We had to be clear on what can we offer.
- 41. Building Strategy Mobile First and selected features Desktop switch • Allow mobile users to view desktop version of site. 41
- 42. Building Strategy Mobile First and selected features Structuring markup to “flow” naturally 42 Think about how you structure your markup ahead of time to plan for re-flow. Here is also where following compliance in markup can help you in the long run. Well formed code avoids problems in the future.
- 43. Building Strategy Front-end mobile and browser testing http://crossbrowsertesting.com 44
- 44. Building Strategy Questions 45
- 45. Q&A / Resources Sites: Example RWD sites http://mediaqueri.es/ RWD tool http://www.responsinator.com/ (quick-view tool) JavaScript image library https://github.com/teleject/hisrc JavaScript image library https://github.com/scottjehl/picturefill/ Advanced image handling http://developer.sencha.io http://docs.sencha.io/current/index.html WordPress RWD theme http://wordpress.org/extend/themes/responsive Drupal RWD theme http://drupal.org/project/omega Books: Ethan Marcotte, Responsive Web Design, Publisher: A Book Apart Luke Wroblewski, Mobile First. Publisher: A Book Apart Progressive Enhancement. Publisher: New Riders 46