Top Banner
USER PROOF YOUR RAILS APPS FOR THE LOWEST COMMON DENOMINATOR @LIZHUBERTZ
11

Designing Your Backend for Better User Experience (Ruby on Rails)

Jul 15, 2015

Download

Technology

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Designing Your Backend for Better User Experience (Ruby on Rails)

USER PROOF YOUR RAILS APPSFOR THE LOWEST COMMON DENOMINATOR !@LIZHUBERTZ

Page 2: Designing Your Backend for Better User Experience (Ruby on Rails)

Q: WHO ARE YOUR USERS?

A. People who attend tech Meetups

B. My 90-year-old grandmother who uses IE

C. A 14-year-old kid on her parents’ iPad

D. Some sassy woman in Spain

E. None and/or All of the Above

Page 3: Designing Your Backend for Better User Experience (Ruby on Rails)

BABYLISTMADE FOR TECH-SAVVY MOMS USED BY LITERALLY EVERYONE

Page 4: Designing Your Backend for Better User Experience (Ruby on Rails)
Page 5: Designing Your Backend for Better User Experience (Ruby on Rails)

THE RESULT

• No matter how much time you put into optimizing user experience, there will always be people who defy expectations.

• Accidents will happen.

• Accounts will be deleted.

• You must be your users’ source control.

DON’T WORRY. I GOT THIS.

Page 6: Designing Your Backend for Better User Experience (Ruby on Rails)

THE WORKAROUND: IS_ACTIVE

• Create a database migration to add column is_active to tables prone to disaster. Which can be ANYTHING a user has the power to destroy - users, registries, items, reservations, etc.

• Command line: rails g migration add_is_active

Page 7: Designing Your Backend for Better User Experience (Ruby on Rails)

YOUR MODELS: OVERRIDE DESTROY

• Now, your problem records live on FOREVER…just in case you need to switch them back to active.

• P.S. - Difference between the destroy method and the delete method. You could override the delete method, but then you don’t get callbacks like before_destroy.

Page 8: Designing Your Backend for Better User Experience (Ruby on Rails)

DEFAULT SCOPE (HIDE THE INACTIVE STUFF BY DEFAULT)

• RegItem.all # SELECT * FROM reg_items WHERE is_active = true;

• Reference: http://apidock.com/rails/ActiveRecord/Base/default_scope/class

Page 9: Designing Your Backend for Better User Experience (Ruby on Rails)

UNSCOPED (OK FIND THE INACTIVE STUFF SOMETIMES)

• Example: Item on registry was deleted by accident. User freaking out because it was this random onesie on Etsy they’ll never be able to find again. Customer support needs to run a query to find the name of the deleted item.

• Source: http://apidock.com/rails/ActiveRecord/Base/unscoped/class

Page 10: Designing Your Backend for Better User Experience (Ruby on Rails)

BENEFITS TO THIS APPROACH• Key user information is never destroyed, so data restoration is 100%

possible. Happy users!

• Restoration is as simple as changing the is_active column to “true” - which means super easy integration for an admin panel. Happy customer support people!

• More data is saved about user behavior. (“On average, accidental deletes happen for 50% of our registry items. Something must be wrong with our user interface.”)

• Simple UI - Users never need to know what they’re doing behind the scenes. There’s no record on their end of inactive vs. active objects. They think they’re just deleting as normal and then assume you have magic powers. Yay!

Page 11: Designing Your Backend for Better User Experience (Ruby on Rails)

FIN.