1 / 13

Converting to Fusebox: asking an old CF app to FLiP *

Converting to Fusebox: asking an old CF app to FLiP *. Challenges Methods Results. Mark Wimer mark_wimer@usgs.gov USGS Patuxent Wildlife Research Center, Laurel MD. * F usebox Li fecycle P rocess. Acknowledgements. THANKS to:

cynara
Download Presentation

Converting to Fusebox: asking an old CF app to FLiP *

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Converting to Fusebox: asking an old CF app to FLiP* Challenges Methods Results Mark Wimer mark_wimer@usgs.gov USGS Patuxent Wildlife Research Center, Laurel MD * FuseboxLifecycleProcess

  2. Acknowledgements • THANKS to: • Free code and advice online, especially from Hal Helms, Sandra Clark, Michael Smith, Steve Nelson, Jeff Peters, John Quarto-vonTivadar, Brian Kotek, Max Porges and the fusebox community in general • Teratech’s staff, training, hosting of MD discussion list, and willingness to host these CF conferences! • The Fusebox and Synthis forums Challenges Methods Results

  3. Challenges • Existing application: things to change • Regular modifications • New vision of application began to build • No documentation • Minimal staff – so who is documentation for? • Starting to lose decision points of app in code • Reinvented control mechanism each time new features added Challenges Methods Results

  4. Challenges: existing app, cont’d • What was good before considering the switch • My newer work tended to smaller file size and separated functions • I had begun to separate out a ‘controller’ (didn’t call it that though) • No documentation yet (hey…nothing to lose!) Challenges Methods Results

  5. Weighing the options to go Fusebox • Motivation to consider it: • Several other apps in house being developed using Fusebox (one in production) • Fellow developer showed interest • No written lifecycle process in use • Fears: • Fusebox 4 relatively new (Fusebox 3 confusing) • Learning curve for ‘suite’: Fusebox, MVC, CSS, FLiP, test harnesses, etc. (all at once!) • Lots of work… but then it always is. • Seemed like an ALL or NOTHING proposition. Challenges Methods Results

  6. Fusebox Project Life Cycle* Req. | Arch. | Build • Wireframe • HTML Prototype • Prototype + Devnotes • Sign off • Architecture + Fusedoc • Final Code (& unit testing) • Integration & Acceptance Testing * THANKS to Michael Smith @ Teratech for this Fusebox Conf 2003 slide

  7. Methods • * • Assemble team for review • (team of clients) • Wireframes • Start building wireframes based on existing apps • Solicit comments using DevNotes • Prototypes • Prototypes screen with DevNotes, 2 rounds • Architecture: in Adalon * [Get Adalon from Synthis – my new favorite software] Challenges Methods Results

  8. Learned from Wireframes • Better to construct them with clients in room • Our clients were distributed • DevNotes method worked, but more real-time updating of wireframes would have been better • Group brainstorming dynamic is different over web • A developer may not be the best person to build them (especially in absence of clients) • Loss of user perspective at critical early stage. Challenges Methods Results

  9. Learned from Prototypes • Create all the screens. Do not skip steps. • Since it was existing, temptation was great to skip. • Especially dynamic sections of screens; i.e. versions of a single screen. • Challenge: global navigation, design are tough to implement early on. • But it wasn’t really early on! • Users familiar with existing application • Should have recruited more newbies. Challenges Methods Results

  10. Learned from Prototypes • Comments on user-testing. • Either paper prototypes or real screens. • Process – is user-testing spelled out in FLiP? • Convincing others above & below that it’s worth it. • If you don’t sit and watch someone fumble with your screens IN PERSON, you’ll never “get” user-friendly. (Except you in the third row, fourth from left, of course) • Need some group discussion – in house • Bounce ideas, code review, help with testing Challenges Methods Results

  11. Directory structure before & after Controller (by user) + Public (explore) + observer (myatlas) + reg. coordinator + proj. coordinator + administrator 13 24 1 - - 71 1 - 60 After: ~350 files Before: ~ 210 files Fusebox Nouns for model & view: Each state project is coordinated at the level of a region. Observers survey each block in a region, recorded on fieldforms. Reports: by block or species. Challenges Methods Results

  12. Screen shots and code during session • Wireframes with DevNotes and comments • Prototypes with DevNotes and comments • Adalon diagramming – pre/post MVC • Adalon for circuit planning • Resulting Circuits – detail examples Challenges Methods Results

  13. Questions/ your feedback • Just how badly am I abusing MVC concepts? • Suggestions on circuit arrangement? • Please find me later if you want to see and make suggestions on: • Adalon project files • Wireframes • Prototypes • Application itself Challenges Methods Results

More Related