Dan WoodsJavaScript, HTML5, Cryptography, Architecture

What is PhotoZero?

● Photo storage● Client-side cryptography● Gallery sharing● HTML5, JavaScript application● Totally stateless

PhotoZero Motivation?

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

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

Things That I Learned

People want PhotoZero!

24H: 375 Photos; 48H: 800 Photos

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

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

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

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!

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

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/

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/

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/

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

Tackling PerformanceManage 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

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?)

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

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/

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

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/

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/

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)

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

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

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?

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