Donate at the office!

The reason they want you to fit in...

http://sethgodin.typepad.com/seths_blog/2009/11/the-reason-they-want-you-to-fit-in.html

Assorted mobile web notes

Another assorted collecction of notes from some old notebooks - including some from Mobile Web 2.0 Summit.

mobile: point of inspiration & entertainment & need
users value dependent on relationship with other users
value in getting data from device
* combine knowledge of users across different screens
valuable data can't easily be replicated/recreated
who owns data? - Key Q

Monetisation is complex
- getting the right, loyal customers
contextual advertising doesn't work in socail media
value is in context + contacts
target people, not content/context
profile based on demographics/behaviour/social interaction
how to calcualte the value of mobile marketing?
Privacy - users must be able to utilise data themselves

1 billion people own a Nokia phone
Nokia make - 450M devices a year / 15 per second
1/2 sale price goes on R&D (£6B) - Europes largest - workd 3rd largest researchers
Devices are all alike - what it does for the user is the differentiator
unlimited is the key to packaging services
Nokia want mobile web browsing at same speed as desktop
- Users want it now
Must make service work across devices

The real battle for real estate is in users pockets!

Users expet the ability to do desktop stuff on mobiles
Younger people want more from/on mobiles
make it REALLY easy for uesrs to do things

people communicate with those closer to them with their mobile.
- content changes in context

people would do more on mobile if it was faster

Most important features on mobile:
1. Internet
2. SMS
3. voice

targeting marketing based on device > which are targetted at demographics

users want to buy via operator portal as they trust it

mobile apps for social networks
- 2 times as often
- 4 times the page view

Make advertising/marketing social graph friendly

apps are hard to change - the web is easy

massive users volumes only come from operator portals

focus on what is key of service - not the platform optimising for.

UX is harder to get right - 10x harder on mobile (as screen is 10x smaller?)

software is the future of differentiation
- software will become key for operators

optimising for more powerful devices is likley to become an issue in the near future.


75% of Africans will never have a PC!
Businesses, not consumers willing to pay for content when consumer has very low disposable income.

turn customers into fans

reexamine business practices - don't just evolve

web browser as runtime
- reuse web developers skills for mobile.
mobile web - moving to apps, not just pages

widgets at epicenter of mobile and web convergence
widgets -for social applications(?)

do we need standards? - who benefits?

 You don't have to be a destination - e.g. Twitter.

Turn users ito a community:
- Engage - reason
- Content - useful or entertaining
- Convergence - acknowledge cahnges in user behaviour
- Loyalty - GREAT experience
- Analytics - Use them - to understand audience need.

"digital" connecting web & mobile.

lots of scope for sponsored experiences/apps
mobile advertising has little opportunity to do big things
where's the value of ads in social networks where content has little or no value.

need for local/regional/national variations of global systems
- things won't be the same across cultures but may be able to learn something

league tables as loyalty drivers
Get users doing something, not just watching
realtime feedback enhances participation
showing location of other users  builds community & loyalty
people want to be part of something - don't need to have a conversation
everyone likes to play - "underappreciation of frivolity"

the thing people want to do mpost with their phones is communicate
8 year mobile adoption curve
netbook as biggest mobile web usage device
mobile - a world of fads

communities may/can/do live longer thna the event/product/property they were created for

make payment simple - tightly integrate with app store / payment channel

will governments end up paying for essential infrastructure?
- if no long term business model to provide it at a price people are willing to pay
- would we want that?

captured informaiton is enriched by knowledge of context

look at web and mobility at the same time

charge for more than just the web - depth of network interaction

converged address book =? defacto social network

where data is physically located affects legal access to that data

open not necessarily free

Digital dividend - mobile opportunity based on digital divide

smart objects
sensorconomy

devices drive everything!!
people will pay for
- new types of devices
- deep integration of services

customers understand and will pay for services

use of web as a platform is accelerating
browser as client for the cloud

OS not a differentiator

dConstruct notes

Just been going through some docs and found my notes from dConstruct.

Please be aware that this is unlikely to be of use or interest to anyone but me.


Elements of a Networked Urbanism
People blame themselves - when usability is poor.
Ubiquitous computing - the future!?
Networked urbanism - but surely not everywhere?!
sustainability - empowerment - privacy
City: "a layered representation of experiences over time"
More than half the world live in cities (including slums & favelas)
squallor & vitality
Component / Resource
- Everything: addressable -> queryable -> scriptable
Consistent / Variable
- static > fluid
Latent / Explicit
- information revealed/available:
-- now actionable responses
-- know more than you want to?
Browse / Search
- choice drives option
-- less happenstance/chance
-- removing personal/local/insider knowledge
-- democratization of information
-- expertise becomes harder
Held / Shared
- possibly easier
- contribute back
Expiring / Persistent
- history reamins and becomes available in new ways
- including new levels of personal information
-- personal reinvention becomes harder
Deferred / Real Time
Passive / Interactive
Wayfinding / Wayshowing
Object / Service
- improved utalization of objects
- increased abstraction
Vehicle / Mobility
Ownership / Use
- change in understanding of consumerism
Schelling / Schoaling
- location of common meeting / soft appointment place/time
Community / Network
- changes in level of minimal acquaintance
- society & community based on levels of not knowing
- association by choice / association of circumstance
-Beware:
-- speed of change
-- changing what don't understand
-- what don't understand (almost certainly more than you realise!)
Consumer / Constituent
- Variation
- require: sensitivity/intelligence/tact
Privacy of information
Serendipity is good - you don't want to remove it


Let's See What We Can See (Everybody Online And Looking Good)
Show you/user and others on a map
- creating a virtual community is a good thing
Social is more important than visual (MySpace?)
Indicate:
- Importance
- Popularity
- Relationship
Holisitc views / Peripheral viewing
Include textual representation of what is being shown
Highlight specific information amongst complex screens
From language to behaviour
- experiencing daat
A physics of information
- applying a dynamic display
- visual models
Indicate possibility
- "sculpt the data into the statue of your choice"
Tuning in patterns
Synesthesia
- one input/experience triggering memory of another
Medium = message - depending on representation
Experience!


What’s Next? How mobile is changing design 
What is our perception of the future?
- Influence
- Bias
Now
- everything is touch
GenY - do things collectively
Mobile generation = born after '91
- have greatest buying power
iPhone - fastest consumer ramp up since DVDs
Touch - 4th largest OS (by popularity)
WebKit - 95% of devices accessing the web
Universal language: HTML + CSS + JS + APIs
Are we already designing for the web of tomorrow?
AppStores - more iPhone apps than Mac apps
Mobile apps are now moving to the desktop (Tweetie)
Constraints of mobile design - lead to greater focus
Design for medium or context?
Context = circumstance/settings
The era of single context web is over
web widgets on TVs
Neurolinguistic programming
Audity|Visual|Kinesthesic
Design is a multifaceted experience
what's next?
- anything
- everything
The future will come from investments made in mobile today!
people/user driven
We are the gatekeepers to the information age
portable + personal + always connected
- collaboration
-(-) "we already know the answer"!

Make It So: Learning From SciFi Interfaces
research behind anthromorphism attempts in software
sound is enought to represent something
- audio interfaces
- can create empathy/emotion with sound
behaviour good - likeness better
- giving more than expect
representaiton embodies/implies additional information
constraints ease learning curves
Inputs should know affected stated
- don't respond to something unusual when users wouldn't really want you too

	Loving Your Player with Juicy Feedback

Unpredictability
Variability
Aiming for desirable emotional response
emotional investment
challenge - fellowship
Perception of achievability
Mechanics -> dynamics -> Aesthetics
meaningful activities
avoid clutter
create iteration
avoid feature driven design
Don't fix what isn;t broken
QWAN - Quality Without A Name
Juciness
- constant feedback
- No goal (task)
- Responsive audio feedback
- Aim to produce an emotional response from user
Bubble wrap
Make user care and think it's cool.
Not for it's own sake (feature)
Interpreting more than what's shown
remove arbitrary constraints



Experience and the Emotion Commotion
It's often counter intuitive
Play - in everything(?)
Experience v object
work/play
prickles/goo
Dialectic - no dualism
embedded intelligence in objeccts
embedded emotion in objects
simple questions = complex answers (& vice versa)
emotion = a mental reaction to physical experience/responses
system output > user input


Materialising and Dematerialising A Web of Data. (Or What We’ve Learned From Printing The Internet Out)
"the front of the train is less crowded"
post digital
real objects - digital identities
beyond digital infatuation & analogue nostalgia
"things I would rather read on paper"
new combination of existing things = all new things
victory/success is a dnagerous thing
screens are a cliche
are we just solving the problems we are causing?
- what about entirely new things?
stuff takes up space and is expensive to move
physical things have more importance
redomaining!

Everyware: Adam Greenfield

 A few quotes and notes that caught my attention while reading "Everyware: The dawning age of ubiquitous computing".  I was inspired to finally get this after hearing Adam speak at dConstruct earlier this year.

Present IT development practices as applied to everyware will result in unacceptably bad user experience.

"If computers are everywhere they had better stay out of the way."

Build it as safe as you can, and build in all the safeguards to personal values that you can imagine.

"in dreams begin responsibilities."

It will not be sufficient simply to say, "First, do no harm."

We're not very good at doing "smart" yet, and we may never be.

"some problems routinely put forward [in ubicomp] are actually AI-hard."

Ubiquitous systems must default to a mode that ensures users' physical, psychic, and financial safety.

ubiquitous systems must not introduce undue complications into ordinary operations.

WMRM DisableOnClockRollback

I've been working on a project which involves using Windows Media Rights Manager (WMRM) Digital Rights Management (DRM).  As part of that project I have been applying rights to specific content (movies in this case)
to meet the rules specified by the client.

Unfortunately I was receiving an error and serchin on the error message returned exactly no hits.

{"Error HRESULT E_FAIL has been returned from a call to a COM component."}
 
at WMRMOBJSLib.WMRMRightsClass.set_DisableOnClockRollback(Int32 pVal)


In case anyone else runs in to this in the future, here's how what the bug actually was.


I was setting a DisableOnClockRollback value of true, but was getting the error when I did so.  A short MSDN search later and and I found http://msdn.microsoft.com/en-us/library/bb649390(VS.85).asp. In it is the line:

This property works only if you have set an expiration date first.


That'll be the problem then.  Another case of the person making the decisions not knowing the whole story.  Ho Hum.

DevDays CountDown App: My Analysis

I promise, this'll be the last time* I post about my DevDays CountDown App.

Now it's all over, it seems a suitable time to do some analysis:

• Why did I write it?
• Why did it get picked?
• What helped me develop the application?
  
• What did I learn from the process?
• What would I do differently next time?
  

Why did I write it?
 A few reasons:

• I thought it'd be cool to write an app that got used in quite a cool, high profile event.
• I had an idea that I thought was quite good.
• I thought it'd be a good opportunity to build some experience with WPF and particularly with WPF animation.
• To prove to myself that I was able to produce a good piece of software that meets a clients requirements.
  

Why did it get picked?
Officially:

"... because of the twitterfeed and because the graphics are actually appropriate"

I think there are several reasons:

• Because I actually produced something that met the requirements. - I was surprised by the number of entries that didn't. (Users won't [usually] use[/buy] a product that doesn't meet their needs.)
  
• Because I actually delivered something. - There were a lot of comments from people who said they were working on something but never posted anything. (There's no reward for not showing up.)
  
• Because the graphics were appropriate. - While I also had some novel. alternative, ideas I knew these wouldn't tie in with the StackOverflow or DevDays brands. (A bit of marketing knowledge helps in software development.)
  
• Because I did more than was asked. - The twitter element wasn't part of the original requirements. (Having something unique is always a good selling point.)
  

What helped me develop this application?

• I made sure I understood what was wanted. - I read the requirements thoroughly. I asked questions and madde sure I understood the answers. I read other people's questions and answers.
• I understood the domain. - I go to quite a few conferences and am keen on understanding their organisation and how they are put together. (This partly ties in with my experiences of organising DevEvening.) Knowing the application domain is essential to good software development!
  
• I've seen lots of different ways twitter has been used at conferences and other comparable events. - This guided how I incorporated the twitter element.
• I have a desire to only do things well, or not at all. - Loads of people can do average. Fewer people will put in more effort to make something really refined and polished. - Good enough isn't good enough!
• I focused on my strengths, not my design skills. - By basing the design on an existing layout, colour scheme and images.
  

What did I learn from the process?

• Make the first user experience great. Optimise for it. (User input handling wasn't brilliant in the first version.)
• Visually stunning (slick?!) and different is good for creating a good first impression. Animation is a good way of adding something new, different and visually appealing to traditional desktop apps.
  
• Make user input handling really solid, smart and tolerant.
  
• People love seeing their own contribution/thoughts (tweets) on screen.
• TweetSharp is cool (despite a few temporary problems) and fluent interfaces are really nice to use. 
• There are a lot of ways user input can get into an application. Consider all of them and 3rd party libraries and APIs as external input and treat them with caution.
  

What would I do differently in the future?

• Better caching of tweets retrieved from the twitter API. So can download many at once and then stagger their display.
  
• Better error logging. - Currently swallowing quite a few exceptions with no logging. - It didn't really matter for this case but could help with debugging.
  
• Better messages to display if no new tweets to show.
• Add unique images for fake tweets.
• Add processing rules for tweet inclusion. Possibilities to consider would include: ignoring retweets; profanity filtering; spam detection and ignoring.
• Ability to play music?
• Better validation of all input.

Right. Must be time to go back to some of my other projects.


*This year! - who knows about the future.

WebAIM: CSS in Action: Invisible Content Just for Screen Reader Users

WebAIM have a cool, useful article here: CSS in Action: Invisible Content Just for Screen Reader Users

I had originally liked to this while experimenting with Posterous, but it had been a bit enthusiastic in including content from the site.

Getting IIS6 working in 32bit mode on a 64bit machine

I had a server up and running hosting various sites.  One of those sites needed to be able to apply DRM wrapping to movies (WMV) files.

Unfortunately the DRM libraries are only available in 32bit versions and it's not possible to call 32bit DLLs from 64 bit processes.  The way round this is to have IIS run in 32 bit mode.

The same applies if  needing to reference any other 32 bit DLLs ffrom 64 bit ASP.NET/IIS.

Based on what I read on the internets, making this change should be quite straight forward.  Despite all the instructions on the web saying ti was just one script to run to make this change I found that more needed to be done.  Incase anyone else has the same problem, here's what I did to get it working.

Uninstall the 64bit version of ASP.NET 2.0.
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -u

Configure IIS to run in WOW64 mode.
cscript.exe C:\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

Install 32bit version of ASP.NET 2.0

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

Enable 32bit version of ASP.NET 2.0 in IIS WebService Extensions

Recreate the existing websites in IIS using same setings as before.  This will use the 32bit versions of ISAPI extension executables, etc.  I tried changing these manually but that didn't seem to be enough.  I assume that there's more to change than I'm aware of. Recreating the web site takes care of all that for me.

Done.


IIS is all or nothing when it comes to using the 32 or 64 bit version.  Yes this meant that all websites on that server needed to be changed to run at 32 bit.  We therefore lose the benefits of the 64bit OS.  If the site becomes as big as the client is hoping we'll move the site doing the DRM wrapping to a different box and put everything back to 64bit so we can make the most of the 12GB of memory installed.

Stack Overflow Dev Days: London

As promised previously here's my review/notes/random thoughts from DevDays London.  Plus I'm keeping this positive this time.

As I was slightly invested in seeing the countdown app in all it's massive screen glory. I was trying my best to arrive in plenty of time.  Unfortunaltely my 3 year old son had other thoughts on me leaving early.  Fortunately I arrived in the "great hall" with a sign on the screen saying "Dev Days starts in 43 seconds". Nothing like cutting it fine!  Seeing all the elements on the screen slide out during the fade to black on a screen the size of my house was definitely cool.

In good tech conference tradition the day started with a comedy video.   I lost count of the in jokes and I've never seen a punchline coming from so far off as the 6 to 8 week deadline estimate.  Plus I'm looking forward to HTML6 and the tag.  Hopefully they'll post the video somewhere, but in the mean time you'll have to make do with this: http://www.youtube.com/watch?v=H3slPNJdbF4.

Pair programming: "You're born alone. You code alone. You debug alone. You die alone."

The first session of the day was Joel (complete with Union Jack flag and I <3 London tshirt) Initially I was concerned that this was just going to be the same presentation he gave at Business Of Software last year. Fortunately there were some new twists on things and some new ideas. My notes:

• Always search everywhere. Never ask the user to say which fields to search.
• Decisions are about balancing simplicity and power.
• Do you do one thing well v/s have lots of features
• More features mean more choices.
• Choice is attractive but too many choices prohibit purchases.
• "The paradox of Choice"
• Less features v/s a defining sense of self
• Don't ask questions the user can't answer.
• Users blame themselves when selecting the wrong option.
• Most people need more than simple.
• Sales increase when features are added
• Power = features; options; capabilities; $
• What do users really care about? - Make something that responds to that. Either directly or indirectly.
• Computers shouldn't set the users agenda.
• Not all features are created equal. There are good & bad features.
• Good features come from or are the result of good design.
• Help users achieve goals v/s interrupt users
• Elegance: don't go on about how good/clever you are.
• [Having to make] decisions waste[s] users time.
• Elegant code is not the same as clean code.
• Elegant code is more than clean. If elegant it "doesn't look like there's enough code".
• Elegant UIs take more work.
• Not requiring user confirmation requires users be able to 'undo' the decisions you make for them.

Didn't pay much attention to the Python talk as it didn't seem that appealing and I was exploring helloapp. - Until my phone died that is.

Due to a last minute reorganisation of speaker order. Joel was back with the rundown on FogBUGZ 7. I already use this at work and for my personal projects but was prompted to investigate some features I wasn't using: integrated crash reporting; the backlog plugin; subcases & tags.  Joel also introduced Kiln.  I'm a beta user for this already but it was nice to see someone else using this.  The surreal side to this whole presentation was that Joel was using the example of developing the countdown app used at each devdays and how you could use FogBUGZ in that process.  I did. Very Deja Vu.

Android
Things that caught my attention:

• No app review process - suprising!
• Home screen widgets
• Background services
• Interprocess comms 
• Universal (in app) search
• 2.0 introduces:
• Bluettoth support
• Integrating contacts from multiple accounts
• Camera APIs
• Device targeting via custom device specifying via IDE plugin - create your own emulator
• Tried to claim that a slow emulator is a good thing. - It forces you to make it fast on the emulator thereby ensuring that it's definitely fast on an actual device
• Form/window/control layout is XML based
• Activities = forms
• Intents (really must find out what these are)
• Native support for SQLite - can share stored data with other apps via a content provider
• New GoogleMobile Analytics tools can be included in apps
• Registered developers can buy developer phones (fully unlocked and available with no contract.)

jQuery

• Uses TestSwarm - for cross browser testing
• Find something > do something
• Create something > do something
• $ is an alias for jquery method
• test code at jsbin.com
• Don't select by just a class name as very inefficient in older browsers (which are slower anyway)
• It fails silently - so if it seems to be doing nothing...
• use single methods for setter and getter
• .live() - allows updating selector for changed/added DOM element
• a pluging is a custom function that's reusable and distributable
• Mobile version coming

Jeff Atwood

• Be willing to fail!
• Read Coders at Work
• SO users are muppets ;)

Qt

Note. Ducked out of demo (second) part of this session to get some lunch/

• Nokia's solutions for native development
• "Being able to debug is the most important thing fro developers" - the reason for the need for Open Source
• Lowering the entry barrier for developers is the key for driving adoption
• Success comes from 3rd party Innovation
• Claims to be "the Java we never got"
• Less code needed to achieve the same as lower level languages (C) - Saving money in maintenance phase
• FREE
• Has it's own IDE - QtCreator

Jon Skeet (& Tony the Pony)

• Users want programs that do what is simple and obvious to them, at that particular time.
• Architects design/create systems that are just as complicated as the real workd by slightly different.
• Evolution has cheated us by not giving us 16 fingers. I would have made us better at counting.
• We (developers) struggle with the difference between continuous and discrete numbers.
• We (developers) struggle with Text: multi-byte chars; combining chars; Turkish
• We (developers) struggle with Time: 12/24 hours; date formats; timezones; Daylight Savings Time.
• Know a bit more than you need to. What problmes are you likely to have if the app/code was extended.

iPhone

• Objective-C is like marmite.
• "and that's why we have to say the same words twice" - WTF?!?
• Obj-C is opinionated and includes a lot of historic baggage. :(

How not to design a scripting language

• Don't read the dragon book. Recommended alternatives: Engineering a Compiler and Modern compiler implementaion in X
• Foreign Function Interfaces: bad in principle but allow calling out to C libraries when need code that executes faster.
• "A good rule for life in general: Don't expose yourself!"
• Things that are bad: eval() and dynamic include/import

Yahoo! Developer Tools

"every browser is a bastard"
Some browser are "differently-abled"
JS Libraries are edge cases
YUI - looks useful, especially CSS grids
YQL - WOW! (see http://www.youtube.com/watch?v=SA4Et1DiVbE)

MISC

A couple of quick notes on the organistaion of the event and applicable to any such event:

• Have a countdown that the speaker can see so that they know when they running out of time, or out of time.  - This is always preferable to someone coming on to the stage to tell them they have X minutes left.
• Have a backup microphone on standby.
• There's no excuse for having unprepared speakers.
• There's no excuse for having unreheased speakers. Speakers need to know how long they will take and what they can do in the time they have.
• Text and code must be visible on the screen to everyone watching (if that's what you're trying to show) - zooming in is fine to highlight a specific thing. Staying zoomed in and having to keep scroll around while zoomed in is not good for anyone. 
• If doing a talk introducing a subject cover:
• 
  
  • What can you do?
  • What do you need to do it?
  • What are thre fundamentals people need to know?
  • What gotchas should people be aware of?
  • What recommendations/tips should people know about?
  • What are the answers to the frequently asked questions?
  • Show a few cool and easy examples.
  
  
  
  
  
  

StackOverflow DevDays - sad rant :(

Yesterday I was fortunate to be able to attend StackOverflow DevDays London.  I'm planning to do a detailed write up about the event shortly.  But just wanted to have a quick moan about a couple of bad points about the day.

Firstly, my phone did this very early in the day:

Phone = paper-weight!

Fortunatley I also had my blackberry with me so was able to take this picture but it only had a little bit of battery left to only allow me a couple of tweets during the rest of the day.  This meant I couldn't be my usual twittering self at a conference thereby missing out on what I find to be a useful part of such events.  This was further compounded as it meant I couldn't engage with helloapp.  I had heard about this when FOWA was on and was keen to see it in action.  On top of not being able to interact via twitter, I didn't take a laptop so couldn't use the web based site.  There was no dedicated mobile interface and the AJAX requirements of the site meant it was unusabel on mobile devices.  I noticed a lot of other people trying and failing to get it working on various mobeil devices. If Carsonififed are interested in adapting helloapp for greater mobile interaction and thereby allowing more people to use it and engage with other attendees I'd love to have that conversation.

Second issue of the day;
At the start of the lunch break I had a chance to talk to Joel about the CountDown app I wrote and he used at the start of the day and during breaks.

• Yes this is the code he used in his Fogbugz/Kiln demo. I had a strong sense of Déjà Vu during this as I used FogBugz to track features and fixes during it's development and also hosted the source in Kiln, as an early beta user.
• Yes this is the app I've written (banged on?) about before.
  

Anyway, because I was talking, I joined the lunch queue late. Before I got to the front of the queue we were told that food had run out but more would be available in 4 minutes. About 10 minutes later we were told some food would be available shortly. A few minutes later the lunch break was over and it was back to business - but still no food available.

Yes, I could have raced to get food when the lunch break started but that wouldn't have helped the 50 or so other people (my estimate) who were still queuing and also didn't get food during the break. 

I gave up waiting when Jeff came on to give his talk. I then skipped the Qt talk to get a sandwich.
All very disappointing.


Proper review and details of all the good bits will follow. Promise!


Note to self for future conference attendance:
1-Take loads of phones (not a problem - but must make sure they're charged!)
2- Get a netbook so can get online while there. This will allow doing things which don't have mobile support - (Boo!). Plus, anything larger than a 10" screen seems to big to carry around all day.

Developing for Windows7 with the APICodepack

My slides from last nights session at DevEvening.

Developing for Windows7 with the APICodepack

View more presentations from Matt Lacey.

iPhone App Site Design Trends

via webdesignerwall.com

Posted via web from mrlacey's posterous

Let's make the web faster - Google Code

via code.google.com

Posted via web from mrlacey's posterous

My StackOverflow DevDays app - in action

The first StackOverflow DevDays was yesterday.  Here's my countdown app in all it's glory.

 

Photo courtesy of Kyle Cronin

DevEvening: MvcContrib & Developing for Windows7

As Alex Mackey has now moved to Australia, I've taken over the running of DevEvening.  Our next event is on October 22nd and, to celebrate my new responsibilities, I'll be talking about developing for Windows 7.  Also on the night Jeremy Skinner will be talking about MVCContrib.

If this is something that interests you whay not come down.

More information and to register to attend at http://devevening12.eventbrite.com/.

11 Mobile web gotchas

Another list I had lying around which better serves the world by being somewhere viewable.

In no particular order:
1. URL lengths
Keep em short:
- because people may have to type them in
- because some devices/browser have issues with long ones (256 char limit in some cases)
2. Image sizes
Should be appropriate to the size of the screen on the device. - Don't include something which won't fit on the screen.
Keep the file sizes small too.

3. Javascript
There are varying levels of support with mobile browsers and some interactions won't work (e.g. there's no mouseOver - as there's no mouse.)
4. Select don't type input
Entering text on a mobile can be difficult. Don't make users have to enter anything they really don't have to. That means (as a general rule) select (from a list, or radio button, or ...), don't type whenever possible.

5. Not all devices support all image formats
You're pretty much safe with PNGs except on older devices.  Be aware if you want to use something else else, e.g. JPGs.

6. Header rewriting
Beware of trying to display a page's content based on headers whihc may have been changed by some proxies or operators.

7. Scroll vertically, not horizontally
It's easy to get lost on a page when you scroll in both directions.  Use vertical scrolling only as no one

8. Varying CSS support
Beware anything other than basic styles on older devices.
Be aware of massive variations in levels of support across older devices.

9. Can't get identical output on ALL devices
You may spend a fortune trying.  Aim for a consistent look and feel instead.
10. Keep page sizes small
General rule: Total page sizes should be < 20KB
Keep all asset (images, CSS, JS file) sizes as small as possible too.

11. Validation is important!
Really helps with trying to ensure cross device support
- http://ready.mobi/launch.jsp?locale=en_EN
- http://validator.w3.org/mobile/

Visual Attention: a psychologist's perspective - Chris Atherton at TCUK09

Check out this SlideShare Presentation:

Chris Atherton at TCUK09

View more documents from Chris Atherton.

My StackOverflow DevDays countdown app - Version 3

We'll now I'm at version 3.0 of my countdown app for DevDays it should be ready for use ;)

For reference:Version 1 - Version 2

This version was created to address the follwoing issues:

• Optimized for screen resolution of 1024x768
• Fixed issue with calculating displayed tweet display height
• Removed hardcoding of sponsor images - they're now loaded from a 'Sponsors' folder on startup. This is to enable easily adding new ones.
• Removed hardcoding of tweets displayed when nothing new tweeted or no internet connection available. - These are now loaded from an XML file. This allows customisation of the displayed messages.
• Defaulted start time to countdown to 9am if started before then. If started after then the timer defaults to 5 minutes. (This only applies if no cmdline parameters passed.)
• Fixed the order that tweets are loaded so oldest are shown first.
• Fixed positioning of twitter profile images.
• Also a few other minor fixes.
  

Source - Compiled binaries - Installer

Now it's even better, please vote for it. ;)

Ten reasons web developers should be considering developing for the mobile web

Excuse the roughness of these notes but I thought I'd post this list I had hanging around.

1. More people using it

• More than before
• And they're using it for longer than before
• Globally more people access the internet from a 'mobile' than a 'PC'.
  

2. Bigger screens

• Have made mobile browsers easier to use
  
• Enable a better experience by allowing the viewing of more than just simple text.
  

3. Better browsers

• Can render as well as some desktop browsers
  
• Even with flash support
• Silverlight mobile coming (apparently)

4. Can get 95% of devices with a single output format

• XHTML-MP

5. Cheaper & easier to do than probably think

• It's not as complex as having to develop WAP (anymore)
• Tooling makes it easier

6. Transcoders aren't good enough as don't consider context

• You can create a better experience if you target specifically to the mobile environment, rather than just rely on a machine trying to guess at what would be best.

7. Wide variety of tools to help you

8. Big companies thing it's important

• Eric Schmidt (Google) - "Mobile devices are the most important technology of all."
• Eric Schmidt (Google) - "Google's future depends on the next internet, on cellphones."

9. Provide new ways of interacting with existing users and opportunity to reach new ones

• New ways to build community
• New ways to build loyalty
• New ways to make money

10. You already do (or should) variations of your site(s) (for accessibility)

• WCAG
• Section508
  

Unit testing has it's place

Joel just published this: The Duct Tape Programmer
Go read. I'll wait.

Ok?

Good.

In it, amongst other things, he seems to come across as saying that unit testing isn't worth it because it doesn't help you ship code/a product/a feature in a really short time frame.

But that's not the point.  Unit testing helps improve code quality by preventing bugs over the long term.  The value of unit testing is in the long term.

In the short term it's often better to have software with bugs in than no software at all.  This can help you beat a competitor to market or win that big new contract.
In the short term you're not worried about making a change to one part of the system and inadvertently breaking something else (which automated testing is really good at identifying) because you're not making changes, yet. You're just writing the initial version.

But, in the long run, if you want to keep that market share and avoid losing customers to a competitor with a more reliable product you need to make your software more reliable and contain fewer bugs.

In the long run unit testing will save you time (well maybe not you directly but the development/testing/QA team as a whole). That's the value of unit testing - over the long term.


I've previously written about the value of unit testing here.

I should hope you think it's slick - I was aiming for F***ing Amazing!

WARNING - this is likley to be controversial. But I aim to promote discussion as much as anything else.

I responded to a request for an application to do a simple task.  One of the comments on my app was "Very slick".  This is of course flattering, but it says a sad thing about software development in general : mediocrity is standard. Fortunately this, hopefully, won't remain the case:

http://gapingvoid.com/2009/04/07/mediocrity-now-howls-in-protest-2/ 

Why would I (or anyone) submit an application which was adequate? What would be the point of half hearted effort?

• Seriously, I don't know.

Yes, with version 2 of my DevDays app, I've gone beyond the original requirements. But why would I (or anyone) do this?

• Because just doing enough isn't going to stand out!
• Because just doing what anyone could do isn't going to stand out!

But isn't that doing unnecessary extra work? Who's going to pay for it?

• The trick is to provide a lot of value for a little extra effort. It's paid for when that work gets you great recommendations and future business.

In my app I've added 'Twitterfall' type functionality. This was relatively simple to add through the use of the TweetSharp library.  The value it adds to the application is great. It turns a passive application into an interactive one. Plus it's a boost to me: I got to try out a new library; I got to interact with Joel and received a boost in confidence that what I had created was good; plus I got some subject matter for a blog post.

Before I go on:

• Yes, I know there are times when there really is no need to do more than the absolute minimum.
• Yes, often there are other external pressures.
• Yes, often a client may have a limited budget.
• Yes, a client may want a very specific thing and not be interested in it being the best it can be.
• Yes, there are probably lots of other resons not to do this - but I'm being idealistic and this is my blog so I'm allowed.

Anyway, what was the point of all this? Oh yeah.

http://gapingvoid.com/2009/06/23/the-quality-print-now-available-individually/

I want to make applications that are truly great and people enjoy and want to use.

I want to immitate someone who was actually a master craftsman who worked with wood. (He was more than just a famous carpenter.)

I want to put effort into what I'm doing and do the best possible job.

I don't want to make software people complain about at work when they compare it to the software they use at home.

I don't want to make a second version of a piece of software for someone because there was a clause written into the original contract that means they have to come back to us for future versions. I'd much rather write the first version of a piece of software and hand over the source code to the client (so they can get anyone they want to make the second version) but still have them come back to me to make the second version because they were impressed with what they received the first time.

I don't want to make commodity software. I don't want to be a commodity developer!

I don't want to make average software. I want to make great software!

This isn't just idle claims. I've actually been putting this into practice with a recent project.  It was a common scenario: Large project and only a fraction of the time needed to complete it to a decent standard.
I saw two options: 1. Work at a reasonable rate and if everything went well end up with something that may be barely acceptable. or 2. Go above and beyond and create something I could be proud of.

Due to a unique set of circumstances (mostly my wife having arranged to visit her parents for two weeks with our son - so I was home alone) I was able to select option 2. Also, fortunately, the requirements of the project were an almost perfect fit with my skills (Windows Mobile, WinForms (desktop), ASP.NET & WebServices) so I stood a reasonable chance of being successful.
I decided that if I was going to undertake the project it was going to be as good as I could make it. This was as much to prove to myself that I could make some thing great in the time available as it was to deliver a great solution.

Yes - I made it very clear that the extra effort was a one off and not indicative of what could be expected in the future. That this was an exceptional level of effort was repeated back to me subsequently by the appropriate parties so I think I got this across.

I should also point out that the project (which I'm not allowed to talk about) was something very cool and something I wanted to see succeed.  The deadline was for a pilot/demo which would be visited by many potential customers. The purpose of the demo was to prove that the technology worked and win, potentially, very large contracts.

So for the 2 months up to the demo I lived the project. It seemed like every waking moment was spent thinking about it, and even now find myself thinking about the next stage - which isn't what I'm working on. And I did loads of overtime (over 100 hours - all unpaid). This included an all nighter after the event when the client moved the deadline for the post event data analysis. I worked through the night (well I had one hours sleep before going in to do anohter full days work) because I didn't see the point in goign to all the effort before hand to make the demo work only to not be able to prove what we'd done.  If you can't (accurately) report on what the system did, did the system really do anything? Was it all just smoke and mirrors?

When it came to the demo:

• the customer was very impressed as what I delivered was better than they had hoped for.
• there were a couple of minor bugs, but because I was there I managed to find workarounds - so no big deal, considering.
• the users of the software were initially wary but after a short time prefered working with the application and didn't want it taken away after the demo.  They were also more productive with it.
• the potential customer we wanted to impress, were very impressed.

So was it worth it?

• I was happy with what I achieved.
• The client was impressed.
• The potenital customers were impressed (and some have already signed some big deals).
• I think, my boss was impressed.

But was it worth it?
I think so. I wanted the project to succeed and was only interested in being involved if it could be really good. (In retrospect I think I only managed to reach the level of 'barely acceptable' by my standards - but these are very high.)  Yes I had to work very hard, but it was better (in my mind) than having just created something average - again.

What if I hadn't gone 'beyond the call of duty'?
- Because of the tight schedules I was keen to see how much I actually got done in a realtively short period of time. I was also keen to know exactly how much time I spent on the project. So I recorded (admitedly only in a basic way) how I spent my time.
In my estimation, if I hadn't put the extra time and effort in, the amount I would have got done would have meant that: there would have been some fairly essential functionality not there; the look and feel of the applications would have been much poorer; there would have been more bugs; the last minute changes that were necessary to actually do the demo couldn't have been made. All of which means (by my reckoning) that if I hadn't put the extra effort in the demo wouldn't have gone ahead.  This would mean that the sales people wouldn't have had anything to show. They would have had a much harder job convincing the potential customers to but their business in the hands of a system they couldn't even see demonstrated.

Yes, I'm sure that if it was necessary some kind of limited demonstration could have been put together - instead of the full working system I created.
No, this isn't a dig at the sales people - it's just an observation that it's much easier to sell something if you can show it working, and working well.

So what did I learn from this:

• Making something great was worth it to the business.
• I am actually very clever and can make the applications I always knew I could.
• I REALLY don't want to work to that level again. (At least not without some serious reward* and only if the impact on family life can be minimized)
• Some other things it doesn't make sense to talk about here.

* Part of the reward in this case is me being able to say "I made that". - At least I will be able to say that when I'm allowed to talk about the project. ;)

Other thoughts:

• This is only possible if developing for someone who wants to make a great system
• I suspect it would be MUCH harder to create a truly great system without a very itterative process.
• Part of the reason that the client was so happy with what was delivered was "exactly what they wanted" not what they actually/initially asked for. I can see 3 reasons this was possible:

1. I had good knowledge of the application domain. (Another reason I was excellently suited to the project.)
2. I spent a lot of time talking direclty with the client to confirm exactly what they wanted and discussing possibilities.  I suspect that if these communications had gone through other parties at least some of information would have become confused or lost. (Time constraints meant that there wasn't time to formally spec everything prior to development. - For the demo version only. This isn't a good way to build large, long lasting, reliable software.)
3. The original 'spec' had reporting as a 'wish list' item. My experience taught me that it was actually essential and internally I promoted this to an 'essential' deliverable.  - I was working on the basis that if you're going to be showing & trying to sell something to people who are only interested in the data that comes out the backend it helps to be able to show that data.  Not only did I show the data but also put it in nice graphs (which everyone deemed was more than they could hope for - I consider that a Saturday well spent).  As I sat in on some of the sales demos, I saw jaws drop in amazement and wonder as we were easily able to show and explain trends in data that no-one had previously been able to even capture.  - I suspect that making sales is much easier when you've been able provoke that response.

Side thought: Is making boring, unremarkable software one of the reasons that many developers don't stay in the industry for a long time?

Yes, I have been influenced by Hugh Macleod and his book.

Errors & FogBugz

Today I saw this: (click for full size)

Yes, it's a stack trace caused by a SQL deadlock.
What's note worthy is that this is on a live, public facing website. - for shame :(

Now how do I report this error?

My StackOverflow DevDays countdown app - Version 2

Based on the announcement that my devdays app will be used in an environment where there is internet access available, I've updated to include the TwitterFall-esque feature that I originally removed.

It now looks like this:

The difference is the twitter messages displayed at the side.  These are looked up based on a search term specified in the config file.  If there are no new messages to display or it's not possible to reach the internet (network down, etc.) then one of an assortment of programmer related quotes is displayed instead.

The processing of commandline parameters is also improved.

Now it's even better, please vote for it. ;)


Source - Compiled binaries - Installer

Learning V Education

"The only thing that interferes with my learning is my education"

— Albert Einstein