Awesome tools for rapid UX prototypes - Letting you focus on the solution!
June 18th, 2009 • Internet, agile, gtd, portal, programming, software development • 1 comment
Comic Life is great for creating story flows in a rough and ready way, with a little style.
Balsamiq is an excellent tool for rapidly creating purposefully low-fi wireframe mockups
Napkee enables you to import Balsamiq mockups and turn them into HTML prototypes! Lovely!
Axure is excellent for rapidly creating interactive prototypes.
Liferay Portal is a pretty awesome portlet container that, with a bit of UX (HTML, CSS and JSP) hacking, enables you to rapidly produce fully functional portals. It comes with a vast array of portlets out of the box, saving you a whole load of time.
JQueryUI is a lovely toolkit for quickly developing interactive prototypes. I’m not completely convinced by it as a production tool (heavy JS? but i could be wrong), but excellent for prototyping
iPhone 3.0 Beta 4 Bluetooth tethering results: Less than 1/3 the speed of USB
April 29th, 2009 • Apple, Internet, iPhone • 1 comment
So, it’s rather slower - 96kbps.
To test it, i tried the ThinkBroadband speed tester, (that i successfully used to test USB tethering), but it failed to complete the test.
I then tried the Broadband speed tester site and got the above results, as well as a 74kbps upload speed.
When (if!) i find time, i’ll go digging and find out if there’s an obvious reason for this - it’s clearly shouldn’t be bottlenecked by the performance of BlueTooth, as it should run up to 3 Mbit/s (http://en.wikipedia.org/wiki/Bluetooth)
iPhone 3.0 Beta 4 + iTunes 8.2 Pre-release = USB Tethering Active Again :)
April 29th, 2009 • Apple, Internet, iPhone • No comments
Yep, USB tethering died in Betas 2 and 3, but with iTunes 8.2 Pre-release and Beta 4, all is working again and it feels wonderfully fast. Well, it’s only running at 336.58 Kbps, but it feels great! As a note, i think the fix was actually iTunes rather than iPhone Beta 4.
Lovely
Now to test the Bluetooth speeds
Important iPhone Push Notification consideration
April 16th, 2009 • Apple, Business, Internet, Objective C, iPhone, programming, software development • No comments
A point worth noting by all iPhone developers considering the exciting opportunities of cloud-side iPhone app notifications - how much will it cost you to provide this service?
An important point to consider.
Presenting BDD Story-driven delivery to project and account managers
April 15th, 2009 • agile, bdd, dsl, programming • No comments
Today, i had the true pleasure of presenting my view of how BDD stories offer real business value to project delivery, quality and to the lives of everyone on a software delivery project.
Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)
It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.
What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.
Part 2: Clarify what documents are written and the associated risks and costs
When the whiteboard was complete, I asked the attendees to consider a number of things:
- At what points during the process are documents produced and by who?
- Of those documents produced, which are directly focused on the business and user requirements?
- Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
- Of the many documents produced, which were open to interpretation and translation?
- What are the perceived risks of having so many documents and periods of documentation translation?
When this work was complete, a few points became clear to the group:
- The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
- Interactions between actors were mostly through written documents
- Few actors following this project process retained a direct focus on the business and end user requirements
- A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
- Vast amounts of document interpretation and translation was going on to produce each document
Part 3: Consider stories
After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:
- I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
- I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
- I then came in with the ace
Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!
It was an awesome session. A lot was discussed and understood.