Download as PDF, PPTX
More Related Content
Similar to Building Rich User Experiences w/o JavaScript Spaghetti
Building Rich User Experiences w/o JavaScript Spaghetti
- 1. Building Rich UserExperiences without JavaScript Spaghetti by Jared Faris @jaredthenerd Saturday, March 17, 12
- 2. About me Saturday, March17, 12
- 3.
- 4.
- 5.
- 6. The Problem Designers tend to think in terms of appearance. Good ones think about usability. Only the very best ones think about programmability. Developers make it worse by not thinking about design Saturday, March 17, 12
- 7. A Typical ProductLifecycle Somewhat dramatized... Saturday, March 17, 12
- 8. Designer Developer Saturday, March 17, 12
- 9. We need this feature Saturday, March 17, 12
- 10. I got this Saturday,March 17, 12
- 11.
- 12.
- 13. I got another great idea Saturday, March 17, 12
- 14. Now you tell me Saturday, March 17, 12
- 15. The developer boltson some more code Saturday, March 17, 12
- 16. And another thing... Saturday, March 17, 12
- 17.
- 18. We don’t ‘really’ need this Saturday, March 17, 12
- 19. Uh, yeah we do Saturday, March 17, 12
- 20.
- 21. The developer boltson some more code Saturday, March 17, 12
- 22. Some time passes ‘Some time’ is defined as: Just long enough that the developer doesn’t remember exactly how his original code works. Saturday, March 17, 12
- 23. I’ve got anew feature Saturday, March 17, 12
- 24. Angry developers can really do this. IT managers be warned. Saturday, March 17, 12
- 25.
- 26. More messy code Saturday,March 17, 12
- 27. The last bug Oh wait, one more Saturday, March 17, 12
- 28.
- 29. The next day... Saturday,March 17, 12
- 30.
- 31. Two weeks pass. Saturday,March 17, 12
- 32. I’ve got anew feature Gahh! Saturday, March 17, 12
- 33.
- 34. No developers wereharmed in the making of this dramatic reenactment. Saturday, March 17, 12
- 35. Additional Features +Short Sighted Architecting = Horrible JavaScript Spaghetti Saturday, March 17, 12
- 36. Why does thishappen? This is where you earn audience participation points. Saturday, March 17, 12
- 37. Some Reasons • JavaScript isn’t real code • We don’t treat client side things as real features • We can’t easily test it Saturday, March 17, 12
- 38. This really allboils down to one thing. We developers suck. Saturday, March 17, 12
- 39. Bonus second lesson We developers suck at interacting with designers (or stakeholders). Saturday, March 17, 12
- 40. Three JavaScript Principles • Decouple everything • Make it testable • Push events, not state Saturday, March 17, 12
- 41. Decouple Everything Start thinking about UI pieces as individual JS objects. Remove dependencies between objects. Apply your OO best practices here too. Saturday, March 17, 12
- 42. Make It Testable Separate DOM dependent stuff into a single layer. Put the rest of the stuff in classes that you can test. Saturday, March 17, 12
- 43. Push Events, NotState Know about the Law of Demeter. Let controls worry about their own state. Inform other controls that “X happened to Y”, not “Y is in X state” Saturday, March 17, 12
- 44.
- 45. Mediator Pattern "The essence of the Mediator Pattern is to "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." -Design Patterns: Elements of Reusable Object-Oriented Software Saturday, March 17, 12
- 46. NavControlMediator itemSelected() unselectAll() Events from some other object Saturday, March 17, 12
- 47. Observer Pattern "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." -Design Patterns: Elements of Reusable Object-Oriented Software Think jQuery $(‘.something’).click() Saturday, March 17, 12
- 48. NavControlMediator itemSelected() viewModel unselectAll() Events from some other object Saturday, March 17, 12
- 49. Knockout.js Template Example Saturday,March 17, 12
- 50. Pub/Sub + FairyDust = Service Bus Pub/Sub is great to make sure events propagate. It stats to get brittle with lots of different controls. Saturday, March 17, 12
- 51. Way Too MuchPubbing and Subbing Saturday, March 17, 12
- 52. Service Bus A service bus is another layer that sits outside controls. Controls that want to communicate speak through it. Your controls are then only coupled to a single thing. Saturday, March 17, 12
- 53.
- 54. Service Bus +Mediator • Controls no longer need to know about others. • We can remove/replace controls individually. • We can add controls that listen to the same events without modifying the publisher. • We can re-use pieces more easily because they work in a standard way. Saturday, March 17, 12
- 55. NavControlMediator itemSelected() viewModel Service Bus unselectAll() Events from some other object ReportMediator itemChanged() viewModel unselectAll() Saturday, March 17, 12
- 56. HistoryControl NavControlMediator itemSelected() viewModel Service Bus unselectAll() Events from some other object ReportMediator itemChanged() viewModel unselectAll() Saturday, March 17, 12
- 57. Questions About Patterns? Saturday,March 17, 12
- 58. A Typical ProductLifecycle Round Two Saturday, March 17, 12
- 59. We need this feature Saturday, March 17, 12
- 60. I got afew questions Saturday, March 17, 12
- 61.
- 62.
- 63. I got another great idea Saturday, March 17, 12
- 64. Ok, Cool Saturday, March17, 12
- 65. And another thing... Saturday, March 17, 12
- 66.
- 67. Two weeks pass... Saturday,March 17, 12
- 68. I’ve got anew feature Saturday, March 17, 12
- 69.
- 70.
- 71. A short timelater... Saturday, March 17, 12
- 72.
- 73. Special thanks to He did the frame art Blame me for everything else Saturday, March 17, 12
- 74. Knockout.js - Observerpattern (pub/sub) http://knockoutjs.com/ Postal.js - Service bus https://github.com/ifandelse/postal.js My Stuff @jaredthenerd jfaris@gmail.com https://github.com/jaredfaris http://jaredthenerd.com Saturday, March 17, 12