Friday 24 December 2010
User Experience for Developers
I have been banging on about users being savvied up on UX and Usability for years now. I am a firm believer that as a developer you should have at least some basic knowledge/experience in this area.
This article sums those points up nicely.
I also like this bit: "But sometimes you just need to cut the middleman and talk directly to the source" and I think Agile takes care of a lot of that.
This article sums those points up nicely.
I also like this bit: "But sometimes you just need to cut the middleman and talk directly to the source" and I think Agile takes care of a lot of that.
Tuesday 21 December 2010
Interesting Usability Links
The first one is about User Expectations with Mobile Apps.
The second is about Accessibility First - for a Better User Experience
The second is about Accessibility First - for a Better User Experience
Monday 20 December 2010
Web Squared: Web 2.0 Five Years On
This is a really good paper, definitely worth a read. This is my favourite part of it:
"If we are going to solve the world’s most pressing problems, we must put the power of the Web to
work—its technologies, its business models, and
perhaps most importantly, its philosophies of openness, collective intelligence, and transparency. And
to do that, we must take the Web to another level.
We can’t afford incremental evolution anymore.
It’s time for the Web to engage the real world.
Web meets World—that’s Web Squared"
"If we are going to solve the world’s most pressing problems, we must put the power of the Web to
work—its technologies, its business models, and
perhaps most importantly, its philosophies of openness, collective intelligence, and transparency. And
to do that, we must take the Web to another level.
We can’t afford incremental evolution anymore.
It’s time for the Web to engage the real world.
Web meets World—that’s Web Squared"
Friday 3 December 2010
Amazon MP3
Last Thursday, Nina and I were looking for music for our Playing with Justice Concert. After determining the set list, we decided to purchase them from the Amazon MP3 website. This is by far the worst place I have ever purchased music.
Firstly, the download failed. Ok no big deal, that kind of stuff happens all the time. Was there an option to re-download though? No! After spending ages searching to re-find the download option, we had to contact the Amazon customer services, who then 'reactivated' the link. Tried a second time, download fails again, re-download link no longer available. Contacted them the third time, this time only 2 out of the 8 songs purchased downloaded and the link once again de-activated.
At this point, I decided to give up and download from iTunes. This is a major flaw in their system design as it does not count for download failure. There is no mechanism in place that allows you to track whether the download was successful or not (not even their player) and therefore ensuring the download link is not disabled.
This is such a waste of Oxfam money and I won't be using their store again. I'll stick to iTunes :)
Firstly, the download failed. Ok no big deal, that kind of stuff happens all the time. Was there an option to re-download though? No! After spending ages searching to re-find the download option, we had to contact the Amazon customer services, who then 'reactivated' the link. Tried a second time, download fails again, re-download link no longer available. Contacted them the third time, this time only 2 out of the 8 songs purchased downloaded and the link once again de-activated.
At this point, I decided to give up and download from iTunes. This is a major flaw in their system design as it does not count for download failure. There is no mechanism in place that allows you to track whether the download was successful or not (not even their player) and therefore ensuring the download link is not disabled.
This is such a waste of Oxfam money and I won't be using their store again. I'll stick to iTunes :)
Friday 15 October 2010
Sunday 3 October 2010
GWT Development Notes
General
The module XML file contains definition of the GWT module, the collection of resources that comprise a GWT application or a shared package. The default XML inherits the core GWT functionality required for every project. Optionally, you can specify other GWT modules to inherit from.
In the module XML file, you specify your application's entry point class. In order to compile, a GWT module must specify an entry point. If a GWT module has no entry point, then it can only be inherited by other modules. It is possible to include other modules that have entry points specified in their module XML files. If so, then your module would have multiple entry points. Each entry point is executed in sequence.
UI Components
Whenever possible, GWT defers to browsers' native user interface elements.
This means that GWT buttons render appropriately in different browsers and on different client operating systems. The benefit of using native browser controls is that they are fast, accessible, and most familiar to users. Also, they can be styled with CSS.
Root Panel:
A Root panel is the container for the dynamics elements of your application. It is at the top of any GWT user interface hierarchy. There are two ways you can use a Root panel, either to generate the entire body of the page or to generate specific elements embedded in the body. The Root panel works by wrapping an element in the HTML host page. By default (that is, if you don't add any placeholders in the host page) the Root panel wraps the body element. However, you can wrap any element if you name it and then, when you call the Root panel, pass the name as a parameter.
Debugging
One benefit of using GWT in your AJAX application development is that you can see the effects of your code changes as soon as you refresh the browser running development mode
http://code.google.com/webtoolkit/doc/1.6/tutorial/buildui.html (part 3)
The module XML file contains definition of the GWT module, the collection of resources that comprise a GWT application or a shared package. The default XML inherits the core GWT functionality required for every project. Optionally, you can specify other GWT modules to inherit from.
In the module XML file, you specify your application's entry point class. In order to compile, a GWT module must specify an entry point. If a GWT module has no entry point, then it can only be inherited by other modules. It is possible to include other modules that have entry points specified in their module XML files. If so, then your module would have multiple entry points. Each entry point is executed in sequence.
UI Components
Whenever possible, GWT defers to browsers' native user interface elements.
This means that GWT buttons render appropriately in different browsers and on different client operating systems. The benefit of using native browser controls is that they are fast, accessible, and most familiar to users. Also, they can be styled with CSS.
Root Panel:
A Root panel is the container for the dynamics elements of your application. It is at the top of any GWT user interface hierarchy. There are two ways you can use a Root panel, either to generate the entire body of the page or to generate specific elements embedded in the body. The Root panel works by wrapping an element in the HTML host page. By default (that is, if you don't add any placeholders in the host page) the Root panel wraps the body element. However, you can wrap any element if you name it and then, when you call the Root panel, pass the name as a parameter.
Debugging
One benefit of using GWT in your AJAX application development is that you can see the effects of your code changes as soon as you refresh the browser running development mode
http://code.google.com/webtoolkit/doc/1.6/tutorial/buildui.html (part 3)
Saturday 21 August 2010
Natural Balance Foods Website
As I'm on a bit of a health food obsession at the moment, I went onto the Natural Balance Foods website and presented with the website I think overall it is pretty good. The background image doesn't interfere with the text or the information. The menus and options are clear and the user experience is generally good as you are able to find all the information you need:
I only have 2 qualms with the website. The first is that it takes forever to place the order, sending information back is such a slow process. The second is the inconsitency of the field layout for the start date and expiry date of the credit card details (as shown below):
This really threw me. Other than those 2 issues I quite like the web site :)
I only have 2 qualms with the website. The first is that it takes forever to place the order, sending information back is such a slow process. The second is the inconsitency of the field layout for the start date and expiry date of the credit card details (as shown below):
This really threw me. Other than those 2 issues I quite like the web site :)
MGMT Website
As fantastic as MGMT are as a band, and it's a pretty cool idea trying to engage their fans into designing their website. There are some really cool pictures and art work people have come up with, however this isn't very practical and from a usabilty perspective is very poor!
You visit the home page and are presented with the following page:
Although the image isn't too bad, it's still fairly noisy and makes text difficult to read, especially when you are looking at events (which has the same background) for concert dates. As this is the most important aspect of a band's site, the information should not be difficult to read.
You move away to the 'Music' part of the website, and boy is this an eye sore. You would probably get eye strain from trying to read what's on there and the whole fan art aspect of it means that the site is inconsistent.
If you then move on to the 'fan art' section you are presented with a gallery of art people have uploaded, by selecting you can change the backdrop....great....however there is no option (or easy way if there is an option) of turning off the fan art element of the site.
Yes it's a nice concept but it makes for a very poor user experience.
You visit the home page and are presented with the following page:
You move away to the 'Music' part of the website, and boy is this an eye sore. You would probably get eye strain from trying to read what's on there and the whole fan art aspect of it means that the site is inconsistent.
If you then move on to the 'fan art' section you are presented with a gallery of art people have uploaded, by selecting you can change the backdrop....great....however there is no option (or easy way if there is an option) of turning off the fan art element of the site.
Yes it's a nice concept but it makes for a very poor user experience.
Saturday 24 July 2010
Tab Bars and Pickers
(Pickerview) or just a picker are the controls with the dials that spin. Pickers are more complex than other iPhone controls.
Pickers can be configured to display one dial or many, by default pickers display text, but many can also be made to display images.
Date picker is the easiest type of picker to implement.
Picker has very few attributes that can be configured from within the interface builder. Date picker is the only one that can be grabbed from the interface builder.
A picker needs to be provided with both a picker delegate and a picker data source. The picker defers several jobs to its delegate. The most important of these is the task of determining what to actually draw for each of the rows in each of its components.
The picker asks the delegate for either a string or a view that will be drawn at a given spot or a given component. The picker gets its data from the delegate. In additon to the delegate, a data source is required. The data source tells the picker how many components it will be working with and how many rows make up each component.
Its very common for the data source and the delegate to be the same object and just as common for that object to be the view controller for the picker's endorsing view.
The data source isn't actually an object designed to hold data.
Root controller to manage swapping of applications other views. Tab bars use icons to represent each of the tabs. 24 x 24 pixel .png pics need to be added to the resources folder.
The root controller controls the very first view that the user will see when your program runs.
'Badge' in the 'Tab bar item' can be used to put a red icon onto a tab bar item, similar to red number placed on mail icon.
For tab bar controller first single click the first tab and use the atttributes inspector to specify nib name for that tab's associated view controller. Then open the identity inspector and change the underlying class of the view controller associated with the tab.
Click the tab again, instead of the view controller gave the tab bar item a title icon.
Root controller to manage the swapping of application's other views.
Tab bars use icons to represent each of the tabs. 24 x 24 pixel .png pics need to be added to the resources folder.
The root controller controls the very first view that the user will see when your program runs.
'Badge' in the 'Tab Bar Item' can be used to put a red icon onto a tab bar item, similar to red number placed on email icon.
For tab bar controller first single check the first tab and use the attributed inspector to specify a nib name for that tab's associated view controller. Then open the identity inspector and changed the underlying class of the view controller associated with the tab.
Click tab again, instead of the view controller gave the tab item a title and icon.
To implement the date picker a single outlet and a single action is required. The outlet will be used to grab the value from the date picker. The action will be triggered by a button and will throw up an alert to show the date value pulled from the picker.
Date picker is relatively easy, creating a picker that holds values requires NSArray, as pickers don't hold values themselves. Instead they call methods on their data source and delegates to get the data they need to display. The picker doesn't care where the underlying data is. It asks for the data when it needs it, and the data source and delegate work together to supply that data. As a result, the data could be coming from a static list, or could be loaded from a file or URL, or even made up or calculated on the fly.
controller.h class can act as both the data source and delegate for it's picker. Unlike a date picker, a regular picker cannot tell us what data it holds, because it doesn't maintain the data. It hands the job off to the data source and the delegate. Instead, we have to ask the picker which now is selected and grab the corresponding data from our pickerDataArray.
Using NSInteger as opposed to int or long means that the compiler automatically chooses whichever size is best for the platforms on which the code is being compiled. It will create a 32 bit processor and a longer 64 bit long when compiling for a 64 bit architecture.
Usually data will come from a property file in projects resources folder. Any line of code that begins with #pragma is technically a compiler directive.
For multi component pickers defining 2 constants will represent 2 components.
Components are assigned numbers, with the left most component being assigned zero and increasing by one each move to the right.
Pickers can be configured to display one dial or many, by default pickers display text, but many can also be made to display images.
Date picker is the easiest type of picker to implement.
Picker has very few attributes that can be configured from within the interface builder. Date picker is the only one that can be grabbed from the interface builder.
A picker needs to be provided with both a picker delegate and a picker data source. The picker defers several jobs to its delegate. The most important of these is the task of determining what to actually draw for each of the rows in each of its components.
The picker asks the delegate for either a string or a view that will be drawn at a given spot or a given component. The picker gets its data from the delegate. In additon to the delegate, a data source is required. The data source tells the picker how many components it will be working with and how many rows make up each component.
Its very common for the data source and the delegate to be the same object and just as common for that object to be the view controller for the picker's endorsing view.
The data source isn't actually an object designed to hold data.
Root controller to manage swapping of applications other views. Tab bars use icons to represent each of the tabs. 24 x 24 pixel .png pics need to be added to the resources folder.
The root controller controls the very first view that the user will see when your program runs.
'Badge' in the 'Tab bar item' can be used to put a red icon onto a tab bar item, similar to red number placed on mail icon.
For tab bar controller first single click the first tab and use the atttributes inspector to specify nib name for that tab's associated view controller. Then open the identity inspector and change the underlying class of the view controller associated with the tab.
Click the tab again, instead of the view controller gave the tab bar item a title icon.
Root controller to manage the swapping of application's other views.
Tab bars use icons to represent each of the tabs. 24 x 24 pixel .png pics need to be added to the resources folder.
The root controller controls the very first view that the user will see when your program runs.
'Badge' in the 'Tab Bar Item' can be used to put a red icon onto a tab bar item, similar to red number placed on email icon.
For tab bar controller first single check the first tab and use the attributed inspector to specify a nib name for that tab's associated view controller. Then open the identity inspector and changed the underlying class of the view controller associated with the tab.
Click tab again, instead of the view controller gave the tab item a title and icon.
To implement the date picker a single outlet and a single action is required. The outlet will be used to grab the value from the date picker. The action will be triggered by a button and will throw up an alert to show the date value pulled from the picker.
Date picker is relatively easy, creating a picker that holds values requires NSArray, as pickers don't hold values themselves. Instead they call methods on their data source and delegates to get the data they need to display. The picker doesn't care where the underlying data is. It asks for the data when it needs it, and the data source and delegate work together to supply that data. As a result, the data could be coming from a static list, or could be loaded from a file or URL, or even made up or calculated on the fly.
Using NSInteger as opposed to int or long means that the compiler automatically chooses whichever size is best for the platforms on which the code is being compiled. It will create a 32 bit processor and a longer 64 bit long when compiling for a 64 bit architecture.
Usually data will come from a property file in projects resources folder. Any line of code that begins with #pragma is technically a compiler directive.
For multi component pickers defining 2 constants will represent 2 components.
Components are assigned numbers, with the left most component being assigned zero and increasing by one each move to the right.
Sunday 18 July 2010
Multiview Applications
Real Power of iPhone platform emerges when you can switch out views based on user input.
Simplest example of a multiview application is a utility app. A utility view focusses primarily on a single view but offers a second view that can be used to provide more detail than the primary view.
Several tab bar apps that ship with the iPhone.
A tab bar is used for selecting one and only one option from among two or more. A toolbar can hold buttons and certain other controls, but those items are not mutually exclusive.
Nearly all multiview applications use the same basic pattern. The nib file is a key player.
The root controller is the primary view controller for the application and as such is the view that specifies whether it is ok to automatically rotate to a new orientation, though the root controller can pass responsibility for things like that to the current active controller.
In multiview apps most of the screen will be taken up by a content view and each content view will have its own controller with its own outlets and actions.
In a tab bar application, for example tapping on the tab bar will go to the tab bar controller, but taps anywhere else on the screen will go to the controller that corresponds to the content view currently being displayed.
Each content view generally consists of up to three pieces: the view controller, the nib and a subclass of UIView.
Content view will always usually have an associated view controller, will usually have a nib and will sometimes have a subclass UIView.
One of the most daunting aspect of creating a multiview app from scratch is that several interconnected objects have to be created.
Toolbar buttons aren't like iPhone controls. They support only a single target action and the trigger that action only at one well defined moment, the equivelant of a touch up inside event on other iPhone controls.
Lazy loading is when the view is loaded the first time it is needed and is a standard way of keeping memory overhead down.
Lazy loading is a key component of resource management on the iPhone and should be implemented anywhere possible.
In a complex multiview application, being responsible and flushing unused objects from memory can be the difference between an application that works well and one that crashes periodically because it ran out of memory,
Simplest example of a multiview application is a utility app. A utility view focusses primarily on a single view but offers a second view that can be used to provide more detail than the primary view.
Several tab bar apps that ship with the iPhone.
A tab bar is used for selecting one and only one option from among two or more. A toolbar can hold buttons and certain other controls, but those items are not mutually exclusive.
Nearly all multiview applications use the same basic pattern. The nib file is a key player.
The root controller is the primary view controller for the application and as such is the view that specifies whether it is ok to automatically rotate to a new orientation, though the root controller can pass responsibility for things like that to the current active controller.
In multiview apps most of the screen will be taken up by a content view and each content view will have its own controller with its own outlets and actions.
In a tab bar application, for example tapping on the tab bar will go to the tab bar controller, but taps anywhere else on the screen will go to the controller that corresponds to the content view currently being displayed.
Each content view generally consists of up to three pieces: the view controller, the nib and a subclass of UIView.
Content view will always usually have an associated view controller, will usually have a nib and will sometimes have a subclass UIView.
One of the most daunting aspect of creating a multiview app from scratch is that several interconnected objects have to be created.
Toolbar buttons aren't like iPhone controls. They support only a single target action and the trigger that action only at one well defined moment, the equivelant of a touch up inside event on other iPhone controls.
Lazy loading is when the view is loaded the first time it is needed and is a standard way of keeping memory overhead down.
Lazy loading is a key component of resource management on the iPhone and should be implemented anywhere possible.
In a complex multiview application, being responsible and flushing unused objects from memory can be the difference between an application that works well and one that crashes periodically because it ran out of memory,
Autorotation and Autoresizing
Auto rotation might not be right for every application. Several apps support only a single orientation rotation.
If auto rotation enhances user experience add it to your app.
Auto rotation is specified in the view controller.
Most of the work in actually moving the pixels around the screen is managed by the iPhone OS. There are three approaches to auto rotation dependent upon the complexity of the interface. With simpler interfaces simply specify the auto resize attributes for all the objects that make up the interface.
More complex interfaces have to handle auto rotation in a different manner. One approach is to manually reposition the objects in the view when notified that the view is rotating.
The second approach is to actually design two different versions of the view in the interface builder, one for portrait mode and a seperate one for landscape mode.
In both cases need to override methods from UIViewController in view's controller class.
Add code to.m file, method already provided (commented out) called shouldAutoRotateToInterface need to uncomment and add code.
Four defined orientations in the way that the phone is held:
Upside down orientation is discouraged as the phone will remain that way if it rings. Most controls default to a setting where items on the screen stay where they are when rotated in relation to the left side and the top of the screen.
For larger items specify new positions when view is rotated to prevent overlapping. To change a control's attributes need an outlet to point to the object that needs to be changed.
The size and position of all views, including controls such as buttons are specified within a property called frame, which is a struct of type GRect. GRectMake is a function by apple that lets you easily create a GRect by specifying x and y positions along with the width and height.
GREct comes from core graphics framework.
Designing portrait and landscape view seperately and swapping in and out is a moderately complex action. Requires 2 completely distinct set of outlets one for each view. Cannot change the size of the default view.
If auto rotation enhances user experience add it to your app.
Auto rotation is specified in the view controller.
Most of the work in actually moving the pixels around the screen is managed by the iPhone OS. There are three approaches to auto rotation dependent upon the complexity of the interface. With simpler interfaces simply specify the auto resize attributes for all the objects that make up the interface.
More complex interfaces have to handle auto rotation in a different manner. One approach is to manually reposition the objects in the view when notified that the view is rotating.
The second approach is to actually design two different versions of the view in the interface builder, one for portrait mode and a seperate one for landscape mode.
In both cases need to override methods from UIViewController in view's controller class.
Add code to
Four defined orientations in the way that the phone is held:
- UIInterfaceOrientationPortrait
- UIInterfaceOrientationUpsideDown
- UIInterfaceOrientationLandscapeLeft
- UIInterfaceOrientationLandscapeRight
Upside down orientation is discouraged as the phone will remain that way if it rings. Most controls default to a setting where items on the screen stay where they are when rotated in relation to the left side and the top of the screen.
For larger items specify new positions when view is rotated to prevent overlapping. To change a control's attributes need an outlet to point to the object that needs to be changed.
The size and position of all views, including controls such as buttons are specified within a property called frame, which is a struct of type GRect. GRectMake is a function by apple that lets you easily create a GRect by specifying x and y positions along with the width and height.
GREct comes from core graphics framework.
Designing portrait and landscape view seperately and swapping in and out is a moderately complex action. Requires 2 completely distinct set of outlets one for each view. Cannot change the size of the default view.
Saturday 10 July 2010
More User Interface Fun (iPhone Dev)
Breaking the process of building a complex application into smaller chunks makes it less intimidating. User interface controls come in 3 basic forms: active, static (or inactive) and passive.
Active Controls involves user participation and something happens (i.e push a button and it fires a method).
Static Control like a text label, user does not interact with it.
Passive Control is something that holds onto a value until a user needs it. Controls don't trigger action methods but the user can interact with them and change their values.
All iPhone controls are subclasses of UI Control.
Because of multitouch interface, all iPhone controls can trigger multiple actions depending on how they are touched. User may trigger different actions with finger swipe then a touch.
Images to be used need to be added to the resources folder.
If images and label views have no user interactions then no need to declare actions.
Choosing any options that causes images to scale can add processing overhead.
Alpha slider any value <1 causes processing overhead as the image is transparent.
Text fields are one of the most complex controls on iPhone dev.
Keyboard is software based. To make it 'go away' need to add code to the controller class.
First responder is the control that the user is currently interacting with.
Changing UIView to UIControl gives the view the ability to trigger action methods.
Fairly common to bounce around xcode and interface builder.
Action sheets and alerts are used to provide the user with feedback. They are used to force the user to make a choice between 2 or more items. They are displayed from the bottom of the screen and display a series of buttons for the user to select from. The user cannot continue until they have made a choice.
Alerts also enforce a response from the user before they can continue.
Delegation is a very common design pattern in cocoa touch.
Action sheets always have a parent, which must be a view that is currently visible to the user.
viewDidUnload() method used for memory management, important to set all controller outlets to nil when the controller has been notified that the view has been unloaded.
Active Controls involves user participation and something happens (i.e push a button and it fires a method).
Static Control like a text label, user does not interact with it.
Passive Control is something that holds onto a value until a user needs it. Controls don't trigger action methods but the user can interact with them and change their values.
All iPhone controls are subclasses of UI Control.
Because of multitouch interface, all iPhone controls can trigger multiple actions depending on how they are touched. User may trigger different actions with finger swipe then a touch.
Images to be used need to be added to the resources folder.
If images and label views have no user interactions then no need to declare actions.
Choosing any options that causes images to scale can add processing overhead.
Alpha slider any value <1 causes processing overhead as the image is transparent.
Text fields are one of the most complex controls on iPhone dev.
Keyboard is software based. To make it 'go away' need to add code to the controller class.
First responder is the control that the user is currently interacting with.
Changing UIView to UIControl gives the view the ability to trigger action methods.
Fairly common to bounce around xcode and interface builder.
Action sheets and alerts are used to provide the user with feedback. They are used to force the user to make a choice between 2 or more items. They are displayed from the bottom of the screen and display a series of buttons for the user to select from. The user cannot continue until they have made a choice.
Alerts also enforce a response from the user before they can continue.
Delegation is a very common design pattern in cocoa touch.
Action sheets always have a parent, which must be a view that is currently visible to the user.
viewDidUnload() method used for memory management, important to set all controller outlets to nil when the controller has been notified that the view has been unloaded.
Handling Basic User Interaction (iPhone Development)
Uses the Model-View-Control methodology. MVC divides all the functionality up into 3 distinct categories.
An outlet is like a pointer that points to an object within a nib.
In the opposite direction , interface objects in the nib can be set up to trigger special methods in the controller class. These special methods are known as action methods.
@synthesize
Releasing objects when you are done with them is very important as iPhone device is constrained.
Delegates are classes that take responsibility for doing certain things on behalf of another object.
Hold down the otpion key, move the cursor over the word so it turns into a crosshair, when it does double click!
- Model - The classes that hold your application's data
- View - Made up of the windows, controls and other elements that the user can see and interact with.
- Controller - Binds the model and view together and is the application logic that decides how to handle the users input.
An outlet is like a pointer that points to an object within a nib.
In the opposite direction , interface objects in the nib can be set up to trigger special methods in the controller class. These special methods are known as action methods.
@synthesize
Releasing objects when you are done with them is very important as iPhone device is constrained.
Delegates are classes that take responsibility for doing certain things on behalf of another object.
Hold down the otpion key, move the cursor over the word so it turns into a crosshair, when it does double click!
Tuesday 25 May 2010
How to Be Un-Agile
1) Insist your team provide you with a weekly update/report/metrics even though all the metrics are readily available and easily accessible.
2) Insist on using a vast array of tools, the more electronic the better
3) Constantly insist on eradicating the board without really using it or giving it a chance.
4) Don't relate your daily update to any of the tasks on the board
5) Don't discuss any of the burn down or update your burn down after the meeting
6) Do your own thing without putting an unplanned task on the board
7) Keep the virtual standups 3 minutes long only specifying what you did without having any kind of virtual representation of the board where you have your stories/tasks in front of you that you can discuss.
8) Add random ad-hoc people to the team mid sprint without re-jigging velocity
9) Don't concern yourself with story points they are useless anyway
10) Try and equate story points to man days
11) Don't concern yourself with velocity etc at the end of the sprint either!
2) Insist on using a vast array of tools, the more electronic the better
3) Constantly insist on eradicating the board without really using it or giving it a chance.
4) Don't relate your daily update to any of the tasks on the board
5) Don't discuss any of the burn down or update your burn down after the meeting
6) Do your own thing without putting an unplanned task on the board
7) Keep the virtual standups 3 minutes long only specifying what you did without having any kind of virtual representation of the board where you have your stories/tasks in front of you that you can discuss.
8) Add random ad-hoc people to the team mid sprint without re-jigging velocity
9) Don't concern yourself with story points they are useless anyway
10) Try and equate story points to man days
11) Don't concern yourself with velocity etc at the end of the sprint either!
Saturday 1 May 2010
New Project, Another Agile Approach
So I've started another project and once again we will have an Agile approach encompassed within our software development approach. I really like working on Agile projects, so hopefully there will be more fun to had.
Significance of the Board
One of the great things about having a physical white board is that it provides social interaction. Everyone gathers around the board and because they are standing up the meetings are likely to be prompt and to the point as opposed to where everyone is sitting and gathered around a screen.
The looming presence of the board, located by the team ensures that stand up meetings are held every day and times adhered too. The fact that it is there, highly visible will prompt at least one or two team members to ensure these take place.
High visibility of the board means that anyone (management, client, other colleagues, other sprint teams etc) should be able to walk up to the board and track the progress of the team without interrupting the team or scheduling lengthy stand up meetings. High visibility means that accountability is more obvious as the stories and tasks are up there along with the owner of the tasks. This means team members are more likely to ensure the success of the sprint as they wouldn't want to let the team down.
Distributed Approach
As feature teams will be located across various locations it is imperative that stand up meetings continue on the days where the teams cannot be situated together. An approach needs to be taken to ensure that an environment as similar as being on site is created. There needs to be a board in some way, shape or form. This could be an electronic board or a real board with a web cam being projected at the board. If the board is electronic then the simplicty of the physical board needs to be retained. It is even more essential that this happens in the distirbuted approach because team members will be a) dialling in b) providing an update c) trying to update post its etc based on their update d) calculating the burn down. This will prove even more complex over a virtual meeting and as multi tasking is required the process needs to be as simple as possible. Even if that means having a basic representation (i.e powerpoint, paint) to capture the teams progress and then added to the 'official' system later.
So why are story points so significant in agile? A lot of the time people tend to misunderstand the purpose of story points. Story points are there to determine the complexity of a story. For instance everyone knows that building a shed is easier than building a house and that building Westminster is much more complex than building a house. We cannot indicate how long each would take to build without breaking it down into smaller tasks. Story points serve the same purpose, the are there to determine the complexity and then tasks relating to the story can then be equated to man days.
As humans we all like to quantify. In general our entire lives are quantified by numbers (how old are you, how much do you weight, how big is the engine in your car). Story points are another way of quantifying the complexity of functionality. Why do we need to do this? The reason behind this is that it doesn't matter how much experience you have, or what grade you are a story size is (for example) 5 regardless. Story points also help determine the velocity of the team and a sustainable pace that they are able to work at. Velocity for future sprints is determined by the story points they have been able to complete in prior sprints.
Finally there is a psychological element behind having story points. There is a great feeling of satisfaction when a story is 'done' and can be marked off on the burn down chart. Story points and getting them into 'done' can also instill healthy competition amongst a project with multiple sprint teams.
Conclusion
Working on Agile projects is great fun. The hard part is getting everyone on board and changing the mindset of those who have not worked in this way before. Traditional methods at a work place (whether that is in IT or other areas) are very hierarchial. The decisions are made by management or higher ups and then filtered down. Those on the ground 'do as they are told'. That's not to say anyone is at fault here, it's just the way it has been and still is. Even society operates in a hierarchial manner.
The key message that needs to be absorbed by those working on Agile projects, for the team is that you are in control and you need to take that control and embrace it. You are the people making the decisions and determining the success of the sprint and in the bigger picture the project. With that comes responisbility, the onus is on you to make it work. If the standup meeting aren't happening, speak up. If something is going wrong or troubling you, share it with the team, do something about it and move on. The key is to take the control and be pro-active. Many people are afraid of this because they are not used to being responsible.
On the other hand, management are afraid of relinquishing control (which is sort of understandable). You need to trust your team, when you trust others without micro managing them and constantly badgering them they are more likely to do a good job because they don't want to let you down. All the metrics you need are up on the board and if you have questions or are feeling troubled you can discuss it with the team. Once you reap the benefits of Agile you will realise how powerful it can be.
Finally, I always see Agile as a form of (Software Development) communism. Everyone pitching in and doing their share for a common goal and every team member pitches in with the decision making.
Significance of the Board
One of the great things about having a physical white board is that it provides social interaction. Everyone gathers around the board and because they are standing up the meetings are likely to be prompt and to the point as opposed to where everyone is sitting and gathered around a screen.
The looming presence of the board, located by the team ensures that stand up meetings are held every day and times adhered too. The fact that it is there, highly visible will prompt at least one or two team members to ensure these take place.
High visibility of the board means that anyone (management, client, other colleagues, other sprint teams etc) should be able to walk up to the board and track the progress of the team without interrupting the team or scheduling lengthy stand up meetings. High visibility means that accountability is more obvious as the stories and tasks are up there along with the owner of the tasks. This means team members are more likely to ensure the success of the sprint as they wouldn't want to let the team down.
Distributed Approach
As feature teams will be located across various locations it is imperative that stand up meetings continue on the days where the teams cannot be situated together. An approach needs to be taken to ensure that an environment as similar as being on site is created. There needs to be a board in some way, shape or form. This could be an electronic board or a real board with a web cam being projected at the board. If the board is electronic then the simplicty of the physical board needs to be retained. It is even more essential that this happens in the distirbuted approach because team members will be a) dialling in b) providing an update c) trying to update post its etc based on their update d) calculating the burn down. This will prove even more complex over a virtual meeting and as multi tasking is required the process needs to be as simple as possible. Even if that means having a basic representation (i.e powerpoint, paint) to capture the teams progress and then added to the 'official' system later.
So why are story points so significant in agile? A lot of the time people tend to misunderstand the purpose of story points. Story points are there to determine the complexity of a story. For instance everyone knows that building a shed is easier than building a house and that building Westminster is much more complex than building a house. We cannot indicate how long each would take to build without breaking it down into smaller tasks. Story points serve the same purpose, the are there to determine the complexity and then tasks relating to the story can then be equated to man days.
As humans we all like to quantify. In general our entire lives are quantified by numbers (how old are you, how much do you weight, how big is the engine in your car). Story points are another way of quantifying the complexity of functionality. Why do we need to do this? The reason behind this is that it doesn't matter how much experience you have, or what grade you are a story size is (for example) 5 regardless. Story points also help determine the velocity of the team and a sustainable pace that they are able to work at. Velocity for future sprints is determined by the story points they have been able to complete in prior sprints.
Finally there is a psychological element behind having story points. There is a great feeling of satisfaction when a story is 'done' and can be marked off on the burn down chart. Story points and getting them into 'done' can also instill healthy competition amongst a project with multiple sprint teams.
Conclusion
Working on Agile projects is great fun. The hard part is getting everyone on board and changing the mindset of those who have not worked in this way before. Traditional methods at a work place (whether that is in IT or other areas) are very hierarchial. The decisions are made by management or higher ups and then filtered down. Those on the ground 'do as they are told'. That's not to say anyone is at fault here, it's just the way it has been and still is. Even society operates in a hierarchial manner.
The key message that needs to be absorbed by those working on Agile projects, for the team is that you are in control and you need to take that control and embrace it. You are the people making the decisions and determining the success of the sprint and in the bigger picture the project. With that comes responisbility, the onus is on you to make it work. If the standup meeting aren't happening, speak up. If something is going wrong or troubling you, share it with the team, do something about it and move on. The key is to take the control and be pro-active. Many people are afraid of this because they are not used to being responsible.
On the other hand, management are afraid of relinquishing control (which is sort of understandable). You need to trust your team, when you trust others without micro managing them and constantly badgering them they are more likely to do a good job because they don't want to let you down. All the metrics you need are up on the board and if you have questions or are feeling troubled you can discuss it with the team. Once you reap the benefits of Agile you will realise how powerful it can be.
Finally, I always see Agile as a form of (Software Development) communism. Everyone pitching in and doing their share for a common goal and every team member pitches in with the decision making.
Wednesday 27 January 2010
Iteration Planning for E 2.1
Today we had our iteration planning session for Elaboration 2 Iteration 1. We have also acquired some new members to the team and project in general. The session went very well, we started using planning poker cards. As many of the members are new to the process it will take a while for a few key concepts to sink in, such as points not equating to man days, trying to understand that the point estimation is an independent process and team members should not concur or reveal their points before everyone does it as a group as this can influence other people's decision. I guess with more practice these things will become second nature.
In the session we managed to estimate points for and discuss the stories and then futher break those stories into tasks assigning effort in terms of time and associating owners.
Generally the morale of the project has gone up, people are understanding and participating in the process and will start to see the fun side to it the more we do it.
I do need to find a good analogy for the points not equating to man days problem.
Here are some statistics from the session:
In the session we managed to estimate points for and discuss the stories and then futher break those stories into tasks assigning effort in terms of time and associating owners.
Generally the morale of the project has gone up, people are understanding and participating in the process and will start to see the fun side to it the more we do it.
I do need to find a good analogy for the points not equating to man days problem.
Here are some statistics from the session:
- 9 Members & 121.5 man days
- 34 points
- 47.25 days to burn
- 45% focus factor
- 7 stories to complete
Monday 25 January 2010
Mental Models
A colleague of mine was in a bit of a predicament earlier and asked for my opinion on mental models. He is currently in the process of designing screens for our project and wanted to know whether he should a) go with his belief that positive action button should be on the right and the negative/neutral on the left (like Apple's dialogs) or b) follow the Windows convention of positive on the left and negative on the right (ok and cancel buttons).
Like many of us he has a fundamental belief that the Windows model is wrong. As much as I wanted to advise to use the 'correct' approach the problem with this is that the majority of users are Windows users and yes people can unlearn and re-train but when we are dealing with a client who may be adverse to such matters it is best to provide them with a screen that depicts *their* mental model as opposed to the correct mental model.
The best approach by far, in this matter would be to mock up both versions and get them to pick so that the onus and ownership belongs to them rather than us. However, this may not be possible with the time constraints. The impression that he has given me is that he is likely to bit the bullet on this particular issue and go with the Windows approach!
Like many of us he has a fundamental belief that the Windows model is wrong. As much as I wanted to advise to use the 'correct' approach the problem with this is that the majority of users are Windows users and yes people can unlearn and re-train but when we are dealing with a client who may be adverse to such matters it is best to provide them with a screen that depicts *their* mental model as opposed to the correct mental model.
The best approach by far, in this matter would be to mock up both versions and get them to pick so that the onus and ownership belongs to them rather than us. However, this may not be possible with the time constraints. The impression that he has given me is that he is likely to bit the bullet on this particular issue and go with the Windows approach!
End of 2nd Iteration E1
The whole point of iterative development is that it a continuous cycle of progress, both in terms of work and skill development so as expected this iteration has been a lot better than the last and we have improved based on the outcome of the last meeting and actions taken. Having a RUP methodology with an Agile flavour means that the teams are working much more closely and collaboratively. Even though this is the case sometimes disparity can still be a problem where everyone is working on their own little patch. I’ve found the best way to remedy this is to keep a continuous dialog open until the knowledge sharing reaches an equilibrium and you are both on the same page. Pair programming/working also helps with this. Sometimes this approach can be a bit intimidating as it might be perceived that you are disturbing said persons or that you don’t have a full grasp of your tasks but the outcome of completing your task competently far outweighs any hesitancy around communication/asking.
For last week's retrospective meeting I have put the comments from the 3 points:
1) What we did well?
2) What we could do better?
3) What we would like to start doing?
up on the white board.
Although we did not manage to get all the stories that we had anticipated into the done column, this iteration was much better in terms of burn down and everyone managed to account their time as you can see from the chart.
One of the big obstacles that we have had is in terms of abstraction and detail, so the leads came up with an idea of ‘brown papering’ starting off at the higher abstract level and drilling down into the detail. This was started mid last week so is pretty much ongoing.
For last week's retrospective meeting I have put the comments from the 3 points:
1) What we did well?
2) What we could do better?
3) What we would like to start doing?
up on the white board.
Although we did not manage to get all the stories that we had anticipated into the done column, this iteration was much better in terms of burn down and everyone managed to account their time as you can see from the chart.
One of the big obstacles that we have had is in terms of abstraction and detail, so the leads came up with an idea of ‘brown papering’ starting off at the higher abstract level and drilling down into the detail. This was started mid last week so is pretty much ongoing.
Friday 1 January 2010
TriBot Test Code
I've writtten some test code for the Tribot (uploaded to the repository). It's just basic test code in a class with a main method, nothing special at the moment.
For the Ultrasonic sensor we have an output to the screen based on readings taken from the surrounding environment.
For the Touch sensor, whilst the sensor is pressed again an output to the screen and same for the colour sensor whilst a reading can be detected an output is displayed to the LCD screen on the brick.
For the motors, the results are physically visible so it's a combination of forward and backwards movement with output to the screen.
The touch, light and motors work fine but I'm a bit worried as the Ultrasonic sensor doesn't seem to be doing much. Maybe it's a coding or LeJos problem. I might use the mindstorms software to test it. I hope it's not faulty :( I don't want to fork out £22 for a new one.
For the Ultrasonic sensor we have an output to the screen based on readings taken from the surrounding environment.
For the Touch sensor, whilst the sensor is pressed again an output to the screen and same for the colour sensor whilst a reading can be detected an output is displayed to the LCD screen on the brick.
For the motors, the results are physically visible so it's a combination of forward and backwards movement with output to the screen.
The touch, light and motors work fine but I'm a bit worried as the Ultrasonic sensor doesn't seem to be doing much. Maybe it's a coding or LeJos problem. I might use the mindstorms software to test it. I hope it's not faulty :( I don't want to fork out £22 for a new one.
Tribot
I spent 5 hours yesterday building the tribot (picture below). It was pretty fiddly to do, there are 2 wheels at the front and 1 small one at the back. As well as that this robot has 3 sensors on it too. The touch sensor, which has a mechanism build around it and a colour sensor on top both of which can be used for object detection. I have also put a sonar sensor on top (looks a bit Johnny 5ish ;-)).
It looks pretty cool, but I'm not entirely convinced about the stability of this bot. I liked the robustness of the old 4 wheel chassis I made (but that was very basic and lacking functionality other than movement) however I haven't programmed the robot as of yet nor tested it so we shall see (I will keep you posted).
It looks pretty cool, but I'm not entirely convinced about the stability of this bot. I liked the robustness of the old 4 wheel chassis I made (but that was very basic and lacking functionality other than movement) however I haven't programmed the robot as of yet nor tested it so we shall see (I will keep you posted).
Subscribe to:
Posts (Atom)