Cross-Browser Testing: Follow-up

This is a followup to my previous post, What cross–browser testing could look like. After talking to a few friends about the idea, we realised one way of running remote Windows instances would be through Amazon EC2.

The weaknesses of this approach are:

  • Installing all the different browsers
  • Trying to get multiple versions of IE set up
  • Where’s Mac OS?

However, it is a definite possibility or at least a nod towards one. Ken from CrossBrowserTesting.com got in touch to show off his service. They’ve got videos of it so you can see it in action without signing up. It’s basically a Java VNC client accessing a set of servers. It’d be interesting to know how they plan to control malicious use of the operating system instances. Also I don’t think you can test local stuff, so you’d need to mirror your work.

Read More →

What Cross-Browser Testing Could Look Like

I build web applications aimed at Windows, Mac OS and Linux. This means I have to test my designs in Firefox, Safari, Opera, Internet Explorer (some clients still need 6 support) and Chrome.

The biggest problem with this is Windows: I can’t run versions of IE side–by–side: I’ve used Multiple IE before, but it’s stopped working on my XP machine. So I have Internet Explorer 7 on my Windows PC, VMware and IE6 on my Mac, and another VMware instance for IE8. That’s 3 Windows licenses. I don’t even use Windows, I do all my development in Mac OS and Linux.

There are products out there that snap images of web sites in different browsers. That’s not really good enough: I need to see behaviour as well as layout.

Read More →

New Project: Quite Useful

I’ve started a new project called Quite Useful. The inspiration is Quite Interesting with a twist on productivity. Currently Quite Useful takes the form of a blog, twitter and delicious account.

I’ve been posting useful everyday tips and software applications with a group of friends from London. We intend to keep things relevant to UK readers, but international content is of course welcome. One area we’d like to focus on is reviewing and promoting UK–based tech startups.

Read More →

LittleBigPlanet Level Design Tips

I recently shared my first LittleBigPlanet level (PSN: ambalek, level name: Saturn 5) and I kept notes as I was making it. It turns out that even though it’s easy to make cool stuff, it’s actually quite hard to make levels that players can understand and play through successfully.

Design tips

  • Think of a solid theme for your level
  • Do some research on your level (I was all over Wikipedia researching Saturn 5 and the Solar System for mine)
  • Make a blueprint with a pencil on paper (it doesn’t matter if you can’t draw)
  • Research other levels to see how to achieve your idea — it’s sometimes hard to create seemingly simple things without a bit of research
  • Use the different grid sizes to quickly lay out materials for the overall structure of the level (press Start for grid options)
  • Get a feel for the camera. I started off creating huge scenes that weren’t visible with the in–game camera (press start for camera options, you can also press down on the d–pad to stop flying)
  • Undo keeps its history even if you switch to play mode, which means you can switch to play mode as much as you like
  • Move the level’s entrance gate to test parts deep within your level
  • Think about who will play your level: I included some education tidbits about the Solar System in mine because I thought kids would like it

Navigation

  • If the player backtracks they should always be able to progress again. It’s easy to create puzzles that can trap the player if they backtrack.
  • Most MediaMolecule levels have a single path, with extra areas for multi–player puzzles and bonuses. It’s probably worth following this scheme so people understand your levels and so they’re easier to test.

Design language and usability

  • Colour code objects the player can grab (default sponge colour)
  • Colour code moving platforms that are part of a puzzle (Mirror’s Edge red object style)
  • Know when to imitate the design language used by MediaMolecule so players can quickly understand your level
  • Clearly mark puzzles that require multiple players
  • Show your working: if you leave buttons visible it makes it easier for the community to learn from you

Building and Complexity

  • Make complex shapes by connecting simple ones: try not to cut complex shapes out of huge blocks (else you can get shape errors).
  • Try to use materials that are close to your desired colour scheme. Using stickers on large objects sometimes causes glitches, and stickers are less vibrant.
  • Using lots of stickers and decorations is a good way to add interest to a scene without raising the level’s complexity too much.
  • Try adding stickers to similar shaped objects, and try over–sizing the sticker so it wraps around the edges of the material. For example, adding the Earth sticker to a circle creates depth.
  • Lifts: Anything that moves needs to come back. Don't take a player somewhere in a lift that doesn't return if they fall off!

Lighting

  • Use lighting to create depth and visual interest, but also to direct the player
  • In a dark level you can use lights to give hints to the player

Physics

Carefully test and adjust mechanical objects to ensure they don’t move too fast or strongly. Strong, fast moving objects can kill the player.

Centrepiece Events

  • Use centrepiece events to tell a story: characters that give hints and “plot” to the player are used a lot in MediaMolecule’s levels
  • Make sure centrepiece events don’t create backtracking headaches

Bonuses

Common techniques for hiding bonuses are:

Read More →

Rails Doesn't Crash a Lot

DHH wrote this: Myth #2: Rails is expected to crash 400 times/day – a response to a myth about Rails processes regularly needing restarts.

I’m a big Rails hacker, it’s 90% of what I’ve done for years. I’ve designed and developed these apps: Tiktrac, Ebiwrite, Helipad, Deadline, Loom and Reuters Real Estate, this blog, not to mention work for smaller clients I haven’t included here. They’re real live applications with constant development, performance and error monitoring.

In the time I’ve been running these applications I’ve never had Rails crash several times a day. In fact, I can’t remember Rails crashing at all except when it’s my fault. Early on I had a cheap Dreamhost account and ran my personal blog on there, and found it crashed due to Dreamhost zapping processes when a server was under load. Now I’ve got dedicated servers (and obviously Reuters do), and we have Rails processes that run from deploy to deploy — this can be weeks or even months depending on the project.

Read More →

Deadline

Here’s a personal project I’ve been working on for a while: Deadline

I find calendars hard to use but I like writing, so I wanted to create a calendar that uses natural language parsing to make sense of text. You can search for words or dates, so typing “next week” shows you all your events for next week.

Read More →

FOWA 08: Social Notes and Observations

Social notes

One of the great things about the Future of Web Apps expo was how polite the speakers were. I caught up with a few during the conference and in the parties afterwards. Simon and I had a chat with Alvin Woon from Plurk (who likes his beers apparently), the guys from Swirrl, the people from Meebo and PhoneFromHere.

I also wandered around the Friday night party weeding out the hackers from the Diggnation fans, thankful to find fellow Ruby and Cocoa programmers present. The amount of UK/EU Microsoft/PHP/Java developers seemed to outweigh the number of Ruby folks, but I found them in the end.

Observations

The UK–centric audience was quiet. Watch videos of an American conference and compare how load they are — I’m not saying they’re like an episode of Jerry Springer but they’re definitely louder. When it came to questions almost every talk had an embarrassing silence until someone could grudgingly force out a question.

Read More →

FOWA 08: Day 2 Talks

This is a summary of the talks I went to at the Future of Web Apps on the second day of the conference. Read the first part here: FOWA 08: Day 1 Talks

The Fear Factor – Tim Bray

Tim changed his talk to one about how to survive in the current economic climate. He basically described my career (I graduated in 2001 – during the dot com crash) so I felt some encouragement from his ideas.

Innovation, the future and why nothing is ever simple – Simon Wardley

Simon’s talk explained why managing software companies is difficult. He centred on the concepts around balancing innovation and competitiveness: how staying ahead of competitors requires different management techniques to innovation and research. The paradox of managing order and disorder.

Read More →