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:
• Bluetooth 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 plugin 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 for 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 world but 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 problems 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 approaches to mobilising your website

Here are some approaches to creating a mobile version of a website. Plus some notes on each approach.


1. Display different pages for different devices.
- Can be problematic when needing to make changes and/or when the number of devices you are supporting increases.

2. Display the same page(s) with different contents when viewed on a mobile device.
- Can be awkward to manage different versions of content. Especially if that means having different size versions of lots of images.

3. Have the same page(s)/view(s) for mobile but use different master pages.
- Obviously only an ASP.NET solution.

4. Use the same page(s), but with different CSS.
- Normally doesn't allow adequate ability to support the difference in context which should usually be applied to a mobile version.

5. Force redirection to different (sub)domain with mobile specific pages.
- Essentially requires maintaining multiple sites and can dilute brand and make SEO harder.

6. Do nothing - and fail
- The site may just not work at all on the mobile browser.

7. Do nothing - and have a poor quality site
- Some things may work but others not. This will very likely lead to frustrated visitors.

8. Rely on network transcoders or transcoding browsers
- Good luck with that. Do you really want to pass up control of what actually gets displayed to the people visiting your site?

9. Don't display anything to mobile users.
- You may have a reason for this but it's probably a bad idea to automatically exclude more than half the people in the world with access to the web.

10. Build a site which works on all platforms
- Beware attempting to implement this ideal and ending up only serving the lowest common denominator

11. Use automatic mobilising tools (instant mobiliser, mobify.me, etc.)
- Could be a good, quick and easy way to get a good mobile version of a site. Possibly as a temporary measure until mobile visitors require and justify something more.

What do I do/use?

A combination of some of the above. Varying on the requirements of a specific project.

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