How to build an alumni network with a small team, clear strategy, and lots of chutzpah Presentation by Joel Fuller, Jason Stroyer, Christina Sponselli, CASE conference, San Francisco, March 2, 2013

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

29. Building Strategy
Mobile development
29

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