All 5 entries tagged Development

View all 51 entries tagged Development on Warwick Blogs | View entries tagged Development at Technorati | There are no images tagged Development on this blog

September 05, 2005

Casual fortunes

Writing about web page http://www.escapistmagazine.com/print/8/14

I hadn't come across The Escapist before but it's an interesting read on the subject of (video) game development. I particularly enjoyed this article on the subject of why developing smaller, indie games is a better bet both financially and as a career than working for (say) EA.

If I went indie and worked for myself creating casual games:-
  • I could make two or three games each year instead of one every two years, for a cost of thousands, not millions.
  • I'd work alone or with a couple of others, not on giant teams rife with politics.
  • I could be my own boss, pick my own projects, own my own intellectual property, set my own hours, and do the marketing right, instead of coping with my idiot publisher.
  • I could do something weird and innovative instead of just tweaking ten-year-old gameplay, and reach an audience ten times as large.
  • My games might sell for years, not months, so I could actually polish them instead of shipping an untested beta in time for Christmas.
  • People might play my games obsessively for months or years, not blow through them in ten hours and move on.
  • And if I do absolutely everything right - which is under my own control - I could eventually earn two or three times my current salary. Or more. Personally.

Of course, these are all "could" and "might". But there's something in it, I think.


April 05, 2005

Rich text editors

A core component of the web applications we've built has been giving our users a means of editing content to go on a web page. SiteBuilder supports this, as does Forums, as does Warwick Blogs, and so they all have to let their authors create HTML. The very simplest way to accomplish this, of course, is to supply the author with a text box and say "Write some HTML here". But as we've designed these applications, it's been clear to us that this isn't a sufficient solution, that many of the authors we hope will use the tools won't be able to write HTML, and won't want to learn.

So what to do? When we were designing SiteBuilder, we were fairly sure we wanted some sort of WYSIWYG editor, and the only ones we identified as being good enough were java applets, so that's what we used. But in Forums, and later in Blogs, a java editor seemed like a heavyweight solution if all that was actually required was a way of doing simple formatting like bold, italic, bulleted lists and so on. Java applets require a big download to get them working, they can be slow and greedy for memory, and they don't always work well across all operating systems and browsers, or on older hardware. So instead, we adopted simple markup, where asterisks around a word, for example, would embolden the word (Textile, it's called).

The world has moved on a bit since then, though, and there are now some other alternatives to Textile or to java applets; there are Flash based text editors, for example, which work in any browser that can run the Flash plugin (ie. almost all of them). And other web application makers have had to solve the same problem as us – how to offer their users WYSIWYG editing in a way that's cross-platform, reliable, lightweight and usable.

Just recently, there's been a small spate (can spates be small? I choose to believe they can) of WYSIWYG editors which require neither java nor flash, but instead work entirely in javascript. TypePad's editor works in this way, as does the recently announced rich text editor within GMail, and there are also a few implementations around which can be used in one's own applications:-

  • Kevin Roth's implementation is the first result on Google if you search for "Rich text editor", and works exactly as advertised.

  • widgEditor doesn't do as much, but the source code is much easier to follow and to extend or modify if you're so minded.

  • FCKeditor is dazzlingly impressive in terms of its feature set, but any attempt to understand what's going on in the source code will certainly cause your head to explode.

There's also a reasonably good article on how to make your own DesignMode-based javascript WYSIWYG editor here and here.

Downsides? All these implementations require DesignMode to be supported by the browser, which means IE5+ on Windows, and FireFox or Mozilla on Windows, Mac and Unix. But it rules out Safari and IE5 on OS X, Konqueror on Linux and Opera. Still, there is at least one good, free browser on which it'll work for every platform. I think it's plausible that at some stage we might integrate one of these editors into WB.


March 01, 2005

Ruby, don't bring your OO to town

Writing about web page http://hivelogic.com/archives/2005/02/27/regarding-ruby-and-ruby-on-rails/

Interesting analysis about programming languages and the merits of similar syntax (Java, C, PHP, Perl) versus an arguably more elegant syntax which is also completely different (Ruby).

My favourite quote within the article, talking about PHP:-

…an over-implemented, omni-present scripting language embraced by new, overzealous programmers who create low-quality code they barely understand.

Sounds like the PHP I know.


October 15, 2004

Is email bad for programmers?

Writing about web page http://www.w-uh.com/articles/030308-tyranny_of_email.html

We've been talking amongst ourselves a little bit recently about how it's hard to continue to do software development effectively once you already have some applications in production. This is inevitable because once you have applications that people are using, they're bound to have questions, there are bound to be things that need adjusting or mending, and all these things represent sources of interruptions which eat into development time.

And it's not just the time taken to read an email or answer the phone, either; it's the time it takes to switch your attention away from what you were doing before, think about something else, then switch back and try to pick up where you left off (context switching).

I was struck, therefore, by this article which asserts that;-

I maintain that programming cannot be done in less than three-hour windows. It takes three hours to spin up to speed, gather your concentration, shift into "right brain mode", and really focus on a problem. Effective programmers organize their day to have at least one three-hour window, and hopefully two or three. (This is why good programmers often work late at night. They don't get interrupted as much…)

If that estimate is even close to accurate then it's astonishing that we ever make anything at all. It's rare for anyone here to get a three hour window without any kind of interruption at all. And by rare, I mean unheard of.

But if you replace "three hours" with whatever chunk of time you think is credible, then the advice given is nonetheless sensible:-

1. Turn off your email client, put your 'phone in "do not disturb".

2. Isolate yourself. Get good headphones. Warn colleagues when you're "in the zone", to minimize their interrupts.

3. Minimize meetings and schedule them to avoid three-hour windows.

4. Become self-aware about warping off and try to un-stuck yourself.

There's a lot more discussion about managing email and how to stem the tide of the inbox, which is interesting too; I'm adding this to my blog list.


July 06, 2004

Basecamp

The guys at 37 Signals do a lot of impressive work. Their Basecamp project management application is impressive, their Defensive design for the web book is great, and their approach to software design is interesting and accords well with some of our practices at Warwick. I would have liked to go to their recent 1 day Building of Basecamp seminar, were it not for the fact that it's a long way to Chicago for a one day seminar. However reading some reviews of the session, I was struck by one bullet point in this review :-

  • "Start everything with the screen design. The screen is the application. The screen drives the functionality, not the other way around. The screen design is the requirements document."

Interesting. We come quite close to this, in that we use lo-fi and Photoshop mockups relatively early on in the process of designing an application. But we don't go quite as far as to define our requirements by designing a screen; we generally have some higher-level requirements to start with, and then the screen mocking-up process serves to tease out the detail of the requirements and define some behaviours to implement the requirement. I wonder how hard it would be to do literally what's being suggested here; have the act of making the mockup be the requirements process.

Actually, thinking about it, we did come pretty close to this once; the FormsBuilder application was initially defined almost entirely by a series of screenshots showing how you could design an HTML form using a web interface with Add/Remove/Edit buttons. So perhaps it's really quite plausible.


Search this blog

Tags

Blog archive

Loading…

Most recent comments

  • I am looking for a children's book I read in the early 1970s about a young girl who found a witch li… by Maggie on this entry
  • Thanks, John. There are always more books to be remembered, so it's good to have a decent source. by John Dale on this entry
  • I'm a bit late to the party, but in the future, you can always ask at http://www.reddit.com/r/tipofm… by John on this entry
  • I remember we had a series of books when I was around 10 years old in the early 80's. One of the boo… by Andrew Uttley on this entry
  • The trainers look great. I have been reviewing stuff on my blogs for a while and is actually the foc… by on this entry
RSS2.0 Atom
Not signed in
Sign in

Powered by BlogBuilder
© MMXIV