The document discusses PhotoZero, a photo storage application that uses client-side cryptography and HTML5/JavaScript. Key points include that PhotoZero aims to empower users by allowing them to control their own privacy and security without relying on corporate policies. The document also discusses lessons learned from building PhotoZero, including the importance of performance, user experience, building on familiar interfaces, and delivering iterative updates based on user feedback.

1. Dan Woods
JavaScript, HTML5, Cryptography, Architecture

2. What is PhotoZero?
● Photo storage
● Client-side cryptography
● Gallery sharing
● HTML5, JavaScript application
● Totally stateless

3. PhotoZero Motivation?
● Can't trust corporate privacy policies
● Privacy policies don't extend internationally
● Once in the clouds, always in the clouds
● Empowerment!

4. Imagine...
Imagine a day in the future where people are buying up GMail, Facebook, and
Twitter accounts like storage lockers...
Once these companies get bought up, what happens to your privacy then?
You can only trust yourself with your
security...

5. Things That I Learned
People want PhotoZero!
24H: 375 Photos; 48H: 800 Photos

6. Things That I Learned
User Experience Is Everything!
● I get frustrated and think its broken if I don't know something is going on
● They won't use your service if it isn't useful to them
● It isn't useful to them if they don't have an indication that it's working
● Erroneous bugs will be reported which is a waste of your time and money
● People like interacting with machines

7. Things That I Learned
Mobile Experience is Everything!
● 85% of initial landings were from mobile browser
● Average person spends over 2 full hours a day browsing mobile
● Camera in phone; picture in phone
● More facebookers use mobile than not

8. Things That I Learned
Build On Familiar Interfaces
● Don't make users "learn" how to use your application
● Build on common interfaces: Facebook, Twitter, Apple
● Photo gallery should "feel" like Facebook's
● Feed scrolling should "feel" like Twitter
● Walk on the path of giants

9. Things That I Learned
Performance, Performance, Performance!!
● They won't use your site if it's slow...
● User experience suffers without good performance
○ Slow page renders
○ Users can't interact
○ No indication that something is happening
● Almost everybody uses Facebook, use their performance as your baseline
○ You'll get a wide berth for improvements!

10. Tackling Performance
● JavaScript "multi-threading" tricks
● Split the work into manageable chunks
● Asynchronously synchronize!
● Use platform tools that are right for the job
● Manage expectations

11. Tackling Performance
JavaScript "multi-threading" tricks... Some things I've tried:
● Create iframe, call its javascript instead of calling it from your document
● Function daisy-chaining for synchronicity
● setInterval to emulate thread-like behavior
The Winner?
● A Combination of All Three!
http://jsfiddle.net/ARR3j/

12. Tackling Performance
Split the work into manageable chunks...
● JavaScript execution time is dependent on the computer executing it
● Chunk the workload to small enough pieces so any platform can handle it
● Ensure that mobile platforms can handle the workload
PhotoZero Specifically
● Break an image into 1k chunks, encrypt and encode those chunks
● Asynchronously send the chunks to the server
● Utilize "workers" to emulate background processing
http://jsfiddle.net/eQzcc/

13. Tackling Performance
Asynchronously Synchronize!
● Give "workers" a reference to their position in the data set
○ Processing is done when all positions are flagged as completed
● Let them finish on their own time and indicate when they are done
● Firing workers asynchronously allows the faster chunks to finish without
having to wait for the larger ones
● This is particularly useful during encryption process as thumbnails may
take longer to generate depending on images.
http://jsfiddle.net/qupBT/

14. Tackling Performance
Use the Platform Tools That Are Right For the Job
● For PhotoZero, PHP was a good back-end choice
○ Built-in MySQL, JSON support; supported by all cheap hosting
providers; great community support; never any extra-libraries needed
● jQuery is a well supported, extensible javascript library
○ If it's not built in or available as a plugin, I can leverage the library's
framework to customize functionality
● Android app uses PhoneGap to keep a single code base
● PhoneGap is a bad choice for some applications
○ Next version of PZ app will be native with custom JavaScript
extensions to WebView
○ 60KB native versus 400+KB PhoneGap
○ Slow initial load times with PhoneGap

15. Tackling Performance
Manage User Expectations
● Users are generally forgiving for longer load times, etc.
○ Facebook, case-in-point.
● Giving users feedback at different stages of operation will make it seem
faster
● Ensure that your application employs the controls already at the user's
disposal
○ Pushing the stop button should stop whatever is going on
○ Pushing the back button should take the user back to wherever they
were -- even in a single page app
● Bookmarks of hashes should bring the user back to where they were
● Follow these rules and users will forgive you for taking a long time to do
things
● Render the DOM before doing any JS processing

16. User Experience
Paramount to the Success or Failure of your App
● Every page should be functional
○ Dedicate only a small part of your landing page to marketing
● Use HTML5 localStorage when available
○ PZ uses localStorage for emulating statefulness
● Cache when available
○ Use HTML5 localStorage to cache session data
○ Remember the cost of localStorage stringify/parsing when considering
it for caching
○ ~2.5MB limit on cache with localStorage!
○ Use server-side caching for 95% read/5% write scenarios
○ Figure out your cache eviction strategy (time, refreshes?)

17. User Experience
Familiarity and Interaction for the User
● Build on what users already know
○ Facebook, Twitter, Flikr, Picasa, Shutterfly
○ User should not have to "learn" how to use your app
○ Functionality should extend to the user's device controls
■ back button, stop button, refresh button, bookmarks
● Constantly give the user feedback
○ This way they will know when they need to click again, refresh again,
stop, back, etc...
● Let the user know when there is an explicit error
○ This way they know they should not refresh -- they will move on

18. User Experience
Thing are not as they appear...
● Emulate statefulness in non-stateful applications
○ HTML5 localStorage is a great choice to serialize session data
● PZ uses hash routers to figure out where the user wants to go
○ Works great for bookmarking and across refreshes
● The user doesn't care that you built a single-page application
○ User wants your application to function as though it is not a single-
page application
http://fiddle.jshell.net/2Wy8d/2/show/

19. Architecture & Design
Use Libraries and Frameworks
● Choose a library or framework that will keep your application DRY
● Write it yourself only if you're sure you're writing it to micro-scale
○ Don't get so committed to your own implementation of something else
that is out there
○ PZ has its own hash router that can be swapped in favor of Ember,
BackBoneJS, etc...
○ The only benefit of rewriting something yourself is to reduce
complexity and dependencies
● jQuery events provide a great way to build a lightweight custom framework

20. Architecture & Design
Write It Once, Write It Right
● Structure functions and objects in a way that will allow core functionality to
be reached from a variety of injection points
● You know up front basically what your application will need to do
○ Login, logout, register, create, read, update, delete, etc...
● Package application logic and business logic discretely
○ application logic: #!login landing should show the "#login" div
○ business logic: if #!login && localStorage.getItem("user") != null ...
http://jsfiddle.net/KFgEZ/

21. Architecture & Design
Think Functionally
● Break your logic into the most atomic components possible!
● Factor out as much as possible
○ Utilize JavaScript's dynamic nature to reach your goals
● Breaking your logic into functional pieces will make it easier to debug later
http://jsfiddle.net/N6fmG/

22. Architecture & Design
Use Object Literal Notation
● Object literal notation is easy to understand
● You can give readable names to discrete logic units
● You can wholesale segment/swap-out full portions of logic by reassigning a
single variable
● Object literal lends itself to maintainability by breaking logic into its own
scope (Crypto vs. Photo)

23. Architecture & Design
Go With Events
● Event driven architecture is the way to go for core functionality
● Will enable your router to get users into the experience through a variety of
injection points
● Creates reusable code
● Will allow you to install asynchronous "wire-taps" at critical points in the
code without impacting user experience
● Decouple core logic from routing logic, application logic, business logic

24. Architecture & Design
DON'T TIE YOURSELF TO A DESIGN
PATTERN!
● One size never fits all
● Design patterns are continually evolving, which means that they are
continually wrong for at least one occassion
● The only important thing is that the code can become familiar
● Allow your design to evolve with the application

25. Delivery
Iterate Rapidly
● stand-up a version and tear it down when you're ready with a fix or feature
● structure your application to allow for code-swapping without impacting
user experience
● if you keep the core functionality principles, then replace UI, layout, etc as
part of your iteration without worry
● rapid iterations will keep you interested in the project
○ how many of you have thrown away projects after losing interest?

26. Delivery
Elicit Feedback From Users
● Users are our "customers" and they are never wrong
● Getting real-world feedback is unparalleled to any amount of QA
○ It'll keep you focused too
○ Don't develop in a "black box", you're setting yourself up for failure
● Passively advertise when features are added or fixes are made
● Give the user some visual indication that they're working with brand-new
stuff
○ change the UI
○ increment a build number, etc
● Use Twitter to divulge release notes
● Notify API developers of new builds through social media