Tag: UX and Design

    App Idea: CatchUp

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Here’s some initial design ideas for a location-aware chat app that, as far as I am aware, has significant new features over and above existing mobile chat apps (iMessage, WhatsApp, BBM etc.) and existing location-based functionality in apps (FourSquare, Facebook check-ins, Google Places).

    Background

    Pictochat

    The inspiration for this idea came, more or less, from the Nintendo DS “Pictochat”application.  PictoChat allows up to 16 users to link their DS consoles over a peer-to-peer WiFi connection, and share doodled messages with each other in real time. Between a couple of DS-using friends, PictoChat is an interesting gimmick, but I first encountered it coming into its own at an anime (Japanese animation) convention called MinamiCon. Here, the concentration of DS users was so high that multiple 16-person PictoChat rooms came into existence, full of people chatting away with other convention-goers.

    This was in 2005, before the now ever-present smartphone really came into its own. What about today? Achieving a critical density of DS users to make PictoChat useful is no longer an issue – a critical density of smartphone users exists at every event and every non-event in the Western world. What if we reimagined PictoChat for the smartphone?

    Concept

    There is one big change to the PictoChat concept that we need to make to have a viable idea – and one big addition.

    Attempting to write using DrawSomething

    • Text, not pictures. The DS’ stylus and resistive touchscreen were ideal for doodles, but not so much for text – though a keyboard was available. Modern smartphones have thumb-friendly capacitative screens, and anyone who’s tried to give textual clues in DrawSomething will tell you that writing text PictoChat-style is a non-starter. This new app needs to be text-based, with optional picture and video sharing, much like MMS.
    • Catching up. The idea of “catching up” provided the app’s working title, and forms a secondary mode for the app. As well as real-time chat between people in close proximity, the app also attempts to solve the problem of “how do I keep in touch with people I did [activity x] with?”. Say, for example, that you are at a concert. Over the course of the event the app detects 20 people in your vicinity. You could chat with them live (though hopefully you paid to watch the band not stare at your phone…), but the app remembers who was there so you can also chat to them afterwards.

    Technical Issues

    There are a number of technical issues that the app would have to address.

    • Privacy. It must be easy for users to indicate that they don’t want to be interrupted by messages, and that they don’t want people to detect your presence and “catch up” with you later.
    • Identification. Integration with Facebook would be desirable to allow users to find their friends on the service. However, the app is providing a semi-public mapping of people to locations, so CatchUp users should not be identifiable to people who are not their friends. Foursquare has struck a reasonable balance here.
    • Connection technology. PictoChat used device-to-device WiFi. This is not ideal for CatchUp as it would prevent users from using their WiFi for other things. A low-power Bluetooth connection is a possibility which would also enforce the “chats must be local” idea. However, if we are going to enable “catch up” chats later, we need a server-side chat backend anyway, so it may be best to route everything through the server and determine user proximity for local chat groups on the server.

    CatchUp Architecture

    CatchUp Architecture

    • Integration to other services. Integration with the Facebook, FourSquare or Google Places API could give users the ability to “check in” and use the chat facility together, increasing uptake. Integration with services like Last.fm could incorporate knowledge of event times and places, meaning that the “catch up” chats can have sensible names like “Justin Bieber Concert, Wembley Stadium, 1/1/2012” rather than “with 312 users at Wembley Stadium, 1/1/2012”.

    Last.fm's Events List

    Last.fm’s Events List

    • Blocking. It must be easy for users to block and report abusive users, prevent them from finding out where the reporter is in future, etc.

    Mockups

    I have produced a couple of user interface mockups for the potential design:

    CatchUp Main Menu

    CatchUp Main Menu

    The main menu of CatchUp presents a simple list of chat opportunities, in reverse chronological order.

    At the top is the “Chat now” area. Pressing there takes you to the live chat for your location, as determined and managed by the CatchUp server. The tile shows where CatchUp thinks you are, and how many people you will be placed in a chat room with.

    Below this is a list of all your “catch up” opportunities. If configured to do so, CatchUp monitors your location in the background. If you stay in a location with enough people for long enough (possibly without having to explicitly open a chat), a “catch up” for that event will be placed in the list. The user can press one of these to be taken to a chat room for everyone who was there. Users can remove the Catch Up from the app (and thus prevent being chatted with by other event attendees) with a swipe.

    Settings will have fine-grained privacy options, for example to prevent the user appearing in others’ Catch Ups without explicit permission, to mark certain locations that Catch Up will automatically deactivate itself in, and so on.

    CatchUp Chat Interface

    CatchUp Chat Interface

    Chatting in CatchUp is a simple affair. As locations may have many people chatting, iPhone-style bubbles are replaced with a more basic appearance – though images and videos can still be embedded.

    Potential Flaws

    No application is without its flaws. Here are some that CatchUp would have to address:

    • User Critical Mass. Any social app is only as good as the number of people using it, particularly if the main use case is live chatting. Facebook integration could help a lot here, as could venue sponsorship such as posters with instructions / QR codes to download the app.
    • Balancing default privacy options. Many (most?) users will never change their privacy options. The default must be restrictive enough that the app does not raise Facebook/Buzz-style security concerns, but permissive enough that Catch Ups are still useful.
    • Web interface? Can Catch Up do without a web interface and run mobile-only like Instagram? Or would a web-based interface be useful so that post-event Catch Ups can be done with a proper keyboard?
    • Permanence. Catch Up needs to strike a balance between permanence (everything is kept forever – but UI becomes more complex and permissions more fine-grained) and impermanence (Catch Ups expire and are deleted – but we may need to allow users to get their data out).

    Naming Ideas

    Aside from “CatchUp”, a number of other names have been suggested:

    • Ketchup (a pun on Catch Up)
    • ReCollect (based on the idea that you can “collect” people at events then chat to them later)
    • LiveChat

    Next Steps

    What’s next for CatchUp is largely down to you.

    I am a UX guy and a Java/Python/PHP developer with zero experience of mobile app development – I can do a mean usability study, but I can’t make this app myself in a sensible amount of time.

    If you want to help make this app, get in touch. I can’t do it without help.

    If you want this app to exist but can’t help, share this post! Eventually it’ll get to someone with the time, skill and inclination to help out.

    And if you have any comments whatsoever, keep on scrolling. I’d love to hear any thoughts or (constructive) criticisms you may have!

    Towards a Simpler Desktop

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    In one of my previous blog posts, “Designing for Granddad”, I examined some of the user interface features that cause my grandfather issues when using his computer, and left a few hanging questions as to how we software designers can make our apps less confusing to the novice computer user.

    As is my unfortunate habit, I spent some of today checking out how work had progressed on the GNOME-shell and Ubuntu Unity desktop environments.  (I enjoyed the eye candy for around three hours before reverting to the UI of least resistance.)  Various complexities in their interfaces irritate me and seem to have provoked the wrath of a community of largely experienced computer users.  This got me thinking about how I would go back the other way, and design a desktop environment for absolute novice computer users – one without many of the frustrations of modern software.

    Gnome-Shell Screenshot

    The Gnome-Shell Interface

    My ideas, roughly distilled into a sort of ‘design manifesto’, are:

    1. One activity at a time.  Here I actually agree with Gnome-shell and Unity’s focus on  full-screen applications, avoiding unrelated yet overlapping windows.

    2. Never hide the means to change activities.  Both Gnome-shell and Unity hide their application switcher during normal use, requiring at least a mouse movement or a click to get it back.

    3. Don’t change state with mouse position.  Novice computer users often have trouble controlling the mouse.  Unity’s auto-hiding dock and Gnome-shell’s “hot corner” could prove frustrating, particularly the latter which completely changes the display when hit.

    4. No system trays.  The distinction between the taskbar and system tray is not well-defined and can be confusing.  Gnome-shell is a particularly bad offender here, with not one but two tray-like areas.

    5. No notifications (unless they help).  Pop-ups confuse and scare novice users.  If at all possible, the app should use a sane default rather than asking a question, and do nothing rather than displaying information.  If a pop-up does appear, it should be helpful and clearly worded.

    6. Stateless apps and background services.  The user wants to get their e-mail. Reading e-mail is a legitimate activity, but leaving a mail client open so that they are notified of new mail is not.  Use background services so that it doesn’t matter which apps are running.

    7. Zero tolerance on UI clutter.  While UX people like me may sometimes deplore clutter and idolise minimalism on aesthetic grounds, for the novice user, every bit of clutter is something that they feel like they should know how to use.

    8. Explain things clearly.  Keep words to a minimum, but ensure that the user always feels confident that they know what clicking a given element will do.

    9. Undo everywhere.  Offer an “undo” option wherever possible.  If you’re dealing with small but important items (such as e-mail), consider offering a non-destructive way of getting e-mail out of the user’s face – “archive” instead of “delete”.

    10. Use icons and words together.  Novice computer users may be young or old, and users of any age may have poor vision or may not speak the language in which the interface was written.  These may result in users finding either icons or words easier to understand on a control.  Providing both, by using clear iconography and simple text together, helps to alleviate this problem.

    I’ve mocked up a couple of interfaces to show a desktop environment that adheres to these principles.  The first shows the “desktop”, taskbar and an example notification:

    Simple Desktop Environment - Taskbar & Notifications

    The second shows the mail app with example messages:

    Simple Desktop Environment - E-mail App

    Is there anything you particularly like or hate about the mockups or the design principles behind them?  Bear in mind that if you consider yourself tech-savvy or a software designer yourself, you’re probably not the target audience for this desktop environment – pretend to be your mother or grandfather for a minute and see how you feel about the suggestions I’ve made.

    I’m happy to go further with these designs if you think it’s useful, and of course your own ideas and suggestions are more than welcome.  The comments section is yours!

    For anyone wondering, the mockups in this post were generated with Mockingbird, an excellent UI mocking web-app.

    Designing for Granddad

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Slate’s recent article, “2011 Was a Terrible Year for Tech”, coins the term “mom-bomb” for the moment that technology journalists declare a gadget so easy-to-use that it is actually useful to people who aren’t technology journalists:

    He begins by praising the gadget’s intuitive interface and its easy setup process, but eventually he finds that mere description doesn’t adequately convey the product’s momentous simplicity. That’s when he drops the mom bomb: This thing is so easy that even my mom could use it.

    I’m blessed with parents that, by and large, ‘get’ technology.  Their VCR never flashed 12:00 (and now they have a DVD recorder); they both have Android phones that they can happily e-mail from.  My grandparents are a different story, of course.  Two of them have almost never used a computer, but my Granddad has a nice new shiny one and uses it regularly.  But as the article points out, what tech journalists and we tech-savvy users think is simple and ‘user-friendly’ often falls far short of the ‘mom (or granddad) test’.

    A few observations spring to mind:

    • Moving photos from a digital camera to a computer is one of the simplest tasks non-‘tech-savvy’ users often want to do.  But when you plug in a digital camera, Windows 7 helpfully pops up this dialog:

    Windows 7 Camera AutoPlay Dialog

    Do I want to “Import Pictures and Videos” using Windows, or using Windows Live Photo Gallery?  What’s the difference?  Do I want to “Copy pictures to [my] computer”?  Do I want to “Download images”? Where will the photos go?  Will they still be on the camera?  I just want to see my photos, so I click “Open device to view files”, but what the heck is “DCIM”?

    • I set Google as his browser homepage, and since then, he has been getting his news not from the BBC News bookmark I created, but using the ‘News’ link on Google’s own menu that appears at the top of its pages:

    Google Menu Bar

    …which is great, except that Google can change that menu at any time.  And of course they are doing exactly that:

    New-Look Google Menu

    To my granddad, and many other novice internet users, the distinction between bookmarks – which only change if you want them to – and web page navigation menus – which can change at the webmaster’s whim – is not necessarily clear.

    • Even simple mouse commands can be unclear and difficult.  In the example above, Google’s instruction to find the new menu is to ‘roll over’ the logo.  When the novice user figures out that means ‘hover the cursor over’, they’re greeted with a JavaScript popup which will disappear again if their cursor accidentally wanders too far from the popup.

    It’s my family duty to be tech support, and occasionally I am called upon to fix things that have actually gone wrong.  But more often than not, I am called upon to try to rationalise a simple task that is unexpectedly complex to perform.  This complexity has usually arisen because the software’s developers and most vocal users are so immersed in common UI paradigms that they just don’t notice that the complexity exists.  For the novice user, on the other hand, even your software’s installation wizard is complexity they’d rather not deal with.

    The Slate article is right to cite Facebook’s user interface as a particularly onerous example of software complexity.  Feeds, live updates, inboxes, hidden inboxes, walls, profiles, Timeline, comments, likes, tags – some users need and revel in that level of complexity, but a significant number just want to, say, see what their kids are up to.  I’m nervous that one day soon, my granddad will ask me to set him up with a Facebook account.  I’ll dutifully comply, log him in, and give him this:

    Facebook User Interface

    Where does one even begin?  There are multiple feeds, multiple menus, pop-up and pop-down boxes.  How do you add one of these “status” things?  How do you add a friend?  How do I send a message to someone?  What’s public and what’s private?  Why is there so much stuff?

    In the world of User Experience (UX) design, we spend so much time thinking about how software will be used and by whom – personas, use cases, red routes and all the rest.  But in the majority of software I see when working with novice users, it seems that either the novice user has not been considered, or their persona is paid lip service while the latest excitingly complicated new features are bolted onto the software.

    As creators of software and of user experiences, I know we can do better than this.

    Do you have any thoughts on how we can design better for the novice user?  Just want to vent about an app with a particularly poor UI, or about a relative with a particularly poor grasp of computing?  Fire away in the comments below!

    Announcing: Daily Promise!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    After a couple of weeks of development – documented here, here and here – I think I’m ready to call Daily Promise version 1.0.

    It’s a site that helps you keep track of your promises day-to-day, giving you a pretty display of which promises you’ve kept when, and letting you compete against your Twitter-using friends to be the best at keeping your daily promises!

    For now, you can find Daily Promise at http://dp.onlydreaming.net.

    I’ll make the same deal as I made with Dynamic Democracy, but doubling the number so that I can be more sure of it taking off, and that’s the following:

    At the moment the site does everything I want it to do, and it’s hosted on a subdomain of my main website, which I have no problem with. What I would like to do is give it its own domain, and start implementing feature requests that people send in. So that I don’t end up spending money on something that’s going to die off quickly, the deal is this: When it gets 20 active users, it gets a domain and some TLC. If it doesn’t make it to that point, it stays like it is.

    So if you’d like to help me make something of this site, please start using it, and show it to any of your Twitter-using friends who might need a little help getting healthy, keeping fit or any other goal that Daily Promise can help them with!

    Daily Promise: Avatars Everywhere!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    After a couple of days and one frantic family-free morning, Daily Promise is getting near completion. Here’s what’s new since last time.

    (This is post number 3 in my series on the development of _Daily Promise. The others are here: Design Sketches, Coming Together.)_

    Friends Page

    Daily Promise: FriendsHere’s the Friends page – again, almost no deviation from the original design sketch. The friends page pulls in the list of people that you follow on Twitter, matches it up against Daily Promise’s user list, and if any match, they’re your Daily Promise friends! They’re simply displayed in alphabetical order, along with a summary of their performance. Invisible users (see later) don’t appear, even to their friends.

    Nicer User Pages

    Daily Promise: User PageClicking on one of your friends takes you through to their ‘view’ page (minus any editing functionality). It also shows you their Twitter bio, and how long they’ve been using Daily Promise.

    Top Users Widget

    Daily Promise: Top Users WidgetThere’s now a “top users this week” widget on the home page, showing the performance of the top 5 users. This resets at midnight on Monday morning.

    Spam your Friends!

    Daily Promise: Tweet BoxTwitter integration now includes boxes suggesting Tweets you might like to make after each significant activity. Just as promised in the “How does it work” graphic, Daily Promise never posts to your Twitter account without you deliberately clicking a “Tweet” button each and every time. Do no evil™!

    Behind the Scenes

    A lot of other stuff has changed in the last few days that isn’t immediately obvious to users:

    • Authentication fixed – users using the alternative login weren’t able to do Twitter things. That’s sorted.

    • Account visibility – your account can now be set to invisible, meaning it won’t appear anywhere – top users, friends lists, etc. New accounts are given a prompt to set their visibility before starting to add promises.

    • Account deletion simplified – you now only have one, nuclear, option for account deletion. It erases all traces of you having used the site. Do no evil™! 🙂

    • Removed promises no longer shown in the history table – ‘cos no-one likes to be reminded.

    • Fill in data for yesterday – when creating a promise, users can opt to enter data for yesterday, giving them something to fill in straight away.

    • History table scrolls – narrow displays can’t fit the whole history table in, so now it scrolls (in reasonably modern browsers).

    • Time zones implemented – we pull the timezone you have set in Twitter, so Daily Promise will roll over to a new day at your local midnight.

    • Crontastic! – we now update stats and things from an hourly timed cron, to avoid extra loading on user-requested pages.

    Next Steps

    This all brings me to the slightly worrying conclusion that Daily Promise is damn near finished. So, where do we go from here? I’ll have a few more days of bug-fixing and implementing features that people request, and then it’s difficult decision time:

    This has been a fun project for the last week or so – does it deserve a domain and advertising, or shall I let it quietly die?

    Daily Promise: Coming Together

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Despite the lack of response to my earlier post, in which I floated my design concepts for “Daily Promise”, boredom won out in the end and I started coding anyway.

    It’s now coming together, and all bar the Twitter-integrated social aspects are largely complete. Here’s how it’s developed:

    Home Page

    Daily Promise: HomeThe social side – top users, etc. – still isn’t implemented, but there’s a reasonable-looking homepage in there. The main body is taken up with a short description and a big graphic explaining how the site works. Side-bar widgets provide the Twitter login and alternative login (bypassing twitter.com). The site now has a proper name, Daily Promise, and with it a logo and style that is reflected throughout.

    Set Up Goals (“Manage”)

    Daily Promise: ManageThe “Manage” page has remained almost exactly faithful to the design. New promises can be created, old ones deactivated and deactivated ones can be activated again. A Tweet box appears for the user to announce their new promise, if desired.

    Daily Performance (“Enter”)

    Daily Promise: EnterAgain, there’s not a lot of difference here between the design and the reality. Each promise has a yes/no choice, and after completing a day’s entries, Tweet boxes appear for the user to let their friends know about their successes and failures. “Winning streaks” aren’t yet implemented.

    Performance Log (“View”)

    Daily Promise: ViewThere’s no ability to scroll through your history yet, but the default display shows 4 weeks (which scroll if necessary). Just as in the design drawings, the history table is followed by a text summary of how the user is doing.

    The “View” page also, with a few additions, becomes a user’s profile page, which is accessible to other users.

    Configuration

    Here you can set your password for the alternative login, and delete your account. It’s exactly as dull as it sounds.

    Friends

    That’s my big job for the next few days! It doesn’t exist yet, but it’s now my top priority.

    Daily Promise: Design Sketches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Current flavour of the month of some of the geek crowd, “Health Month”, is a social network of sorts on which users compete to achieve certain health-related goals. Each month, each member sets a number of goals for themselves to achieve. Its core mechanic is health points – you start with 10, lose one every time you fail to meet a goal, and players who perform well can heal you.

    I’m enjoying my use of the site with three goals this month, but I’d like to step it up and set lots. Unfortunately, having more than three goals costs money. (Not that I think the site’s owners don’t have a right to charge, but it can be a deterrent to users such as myself.) It also currently only allows two “custom” rules per month – beyond that, you have to stick with the pre-defined ones.

    Another social health site is Tweet What You Eat, on which users tweet their food intake and have the site, or the community, calculate statistics such as their calorie intake.

    Over my lunch hour, I’ve come up with some sketches for a site that sits somewhere between the two. It takes Health Month’s goals mechanic, opens it up and removes some of the social aspects that in my opinion Health Month doesn’t implement all that well. It also drifts closer to Tweet What You Eat, in that rather than being its own service it piggybacks of Twitter for its social side.

    At the moment this is just a fun concept I’m toying with – I don’t really have the time to make it at the moment, I doubt the space between Health Month and Tweet What You Eat is wide enough to make a new site popular, and I feel a little guilty about thanking Health Month for the enjoyment I’ve had by becoming its competitor.

    In the notes below it’s dubbed healthi.ly, though as that domain is parked, it’s come to be known as “Daily Promise” instead.

    Home Page

    Daily Promise Home PageThe home page would largely be a “log in / register” affair, possibly also showcasing successful and popular users in a side-bar (not shown). Big banner text explains the rough concept, with a “read more” link to a full “About” page. On the registration side, we make it clear exactly what Daily Promise does and doesn’t do with access to your Twitter account.

    Set Up Goals

    Daily Promise Goals PageThe main setup page is where you set your goals. Users can set any (reasonable) number of goals, they can drop and resurrect old ones, and add new ones, at any time. Performance against all the goals is tracked and visible on this page. Adding new goals and dropping old ones can be tweeted, but as with every tweet opportunity, the user is presented with an @Anywhere box that they can freely edit and can choose not to tweet as easily as they can choose to tweet. The tweet links to the list of goals on their profile.

    Daily Performance

    Daily Promise Daily Performance PageOnce goals are set, the user logs in each day (and can fill in past gaps) with whether or not they have met each goal. Each day’s entry presents some brief statistics, and you get more stats on the week after filling in Sunday’s performance. Very good or very bad performance suggests a Tweet that a user might like to make. The tweet links to their performance log on their profile.

    Performance Log

    Daily Promise Performance LogThis is a user’s main screen. It displays a chart of passes and fails for the last month or so as green (pass), red (fail) or grey (goal not active) squares. Below the chart, more detailed stats are presented, as well as an encouraging text summary of how the user is doing.

    Settings

    Most of the core settings such as username, display name, avatar and bio are handled by Twitter. Daily Promise’s settings probably boil down to privacy (stop me being searchable, delete my account, etc.) and removing annoyances (always tweet on condition x, never tweet on condition y, etc. – all of which have an “ask me” setting by default).

    Friends

    Daily Promise Friends PageThe user’s “following” list from Twitter is used to generate their list of Daily Promise friends. Avatars, usernames and Daily Promise performance summaries are displayed here. Clicking through to a user’s profile shows the “performance log” page, topped with name / avatar / bio / etc.

    So, and interesting idea, or an appalling one? Would you use this? Should I get off my arse and code? Should I have finished the last six things I started before prototyping something new? Your thoughts are, as always, appreciated.

    a thousand words: Finishing Touches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    The vast majority of user-reported bugs and requested features on “a thousand words” have now been sorted out. As requested by my co-conspirator Eric, we now have an ‘adult content’ filter based on a date of birth field in users’ profiles, and a ‘report’ button to bring problematic stories and pictures to the attention of the moderators. There’s also a DeviantArt-style “request critique” option to let users know what kind of comments you’re looking for.

    Timestamps have been fixed, “no stars yet” ratings introduced, and text field policies such as “mustn’t be empty” have been added across the site. A few rendering issues in IE have been sorted out, so it now looks much the same across all platforms.

    The biggest change is unfortunately something most of you will never see – the moderator console. Picture submissions and reported stories/pictures now sit in queues that can be dealt with by moderators. An item entering a queue triggers an e-mail to all mods, who are invited to review it and make changes as appropriate. Once changes are made, the affected users are then e-mailed to let them know what happened (and in the case of reported items, to give them a chance to challenge it).

    There’s one major feature request that’s not yet been implemented: file uploads. Once in the system this would allow users to submit pictures from their hard drives rather than from the web by URL, and would allow moderators to copy URL-linked pictures to the site to avoid hotlinking. (At present we don’t hotlink, but we do therefore have to copy pictures to the site manually using FTP.) It could also allow users to use a non-Gravatar picture for their profile.

    Depending on how things go, that may or may not be ready by tomorrow night. On Saturday morning I jet off to sunny Saudi Arabia, so any changes not made by then are going to remain unmade for a while. From that point it’s in Eric’s capable hands as to whether she wants to release the site or not. Even if the site does advance to release status, I’m still taking bug reports (they’ll sit in my inbox until I get back), so keep on letting me know what’s broken and what you’d like to see added!

    a thousand words: Alpha, Beta

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    “a thousand words” has now reached a stage where every feature that I give a damn about is implemented. Thus, we’re opening it up to a limited beta test to iron out the wrinkles and get a list of any features potential users would like to see us launch with. If you’re bored or simply have a love of breaking other people’s shit, head along to http://athousandwords.org.uk and see what hell you can raise. As the Big Red Box Text warns you, really don’t submit any work of fiction you care about, just in case some kind soul finds an SQL injection vulnerability and trashes the database.

    Since last time I bored the hell out of you all, voting and commenting has been implemented, registration has been fixed, filtering HTML tags from submissions has been added, as has a word count and the picture selector on story submission. There’s been a bunch of behind-the-scenes tweaks to improve security too.

    The one feature that Eric definitely wants is a way to mark stories according to their content. We could do this in several ways – I would prefer, if anything, to just have a “not for kids” option on each post and a Date of Birth field associated with user accounts, so we can hide stories as required. Other options include a range of ratings (U, PG, 12, 15, 18…) or tags for certain content (violence, sex, language) so people can avoid whatever they’re picky about.

    This probably ought to come with a Report button so that users can report incorrectly rated stories, and I would add a similar feature to report pictures. (Picture submissions are moderated, so Goatse isn’t going to make it through anyway, but the mod team might miss subtler things like licencing terms and copyright infringement.)

    At that point, all that’s left on my list is the admin interface and anything that users suggest during this beta. Hopefully we’ll be ready to launch by the time I depart for sandier shores at the end of the week!

    a thousand words: Hot Profilin’ Action

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    A few days’ laziness (by which I mean a few days’ Starcraft) have passed with not much work being done on “a thousand words”. That came to an end tonight, with a productive evening resulting in a working profile system so that users can now add and display personal information, change their registered e-mail address and password, etc.

    There’s now a database backend for the voting and commenting systems, which will be complemented by their GUI pages tomorrow night.

    Once that’s done, that’s the last of the main functions out of the way and we’re basically down to tweaks. I think we ought to, in no particular order:

    • Decide on what formatting users can add to stories, and filter for it

    • Add a word count, and possibly limit submissions to e.g. 600-1400 words

    • Add a means of reporting stories and pictures for e.g. copyright issues

    • Add a means of rating stories, so users can mark them as containing sex, violence etc.

    • Create an admin interface, so we don’t just have to run the site with raw SQL queries

    • Add ranks, etc. (incentives for achieving high Total Stars)

    • jQuery up some of the main bits to improve user experience

    • Implement the scrolling list of pictures for users to select when creating a new story

    At that point, I think it should be ready for open beta. Hopefully we can get it all done within a week, before I depart for internet-less shores!

    a thousand words: GETting and POSTing

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Another day, another bunch of functionality added to a thousand words. With the main public-facing interfaces largely complete, I have moved on to the guts of the site’s user interaction. The site now has working, but ugly, implementations of:

    • E-mail address / password authentication, with cookie support based on a secret phrase generated at registration.

    • Registration itself, including the setting of a display name (users authenticate with their e-mail address, so we need something friendlier to display in the UI). Accounts are created in an unactivated state, and an e-mail is sent allowing the user to use their secret phrase to activate the account (GETted via a “click here to activate!” URL).

    • Picture submission, which adds the submission to a ‘queue’ table. In time there will be an admin interface for moving items from the queue to the real pictures table, i.e. promoting a suggested picture to “picture of the week” status.

    • Story submission, which adds the story to the live site and takes you there after submission. There’s currently no edit capability, and the picture that the story is based on must be manually specified by ID number. (The latter will become a scrollable jQuery list of all pictures.)

    A story edit/delete interface is my next task, and once that’s done, the core functionality (excluding any user profile-related code) will be largely finished. After that there’ll be a period of testing and improving the interfaces of the new functions, before I put a call out for a couple of willing guinea pigs to try and break the site for me! If anyone out there is expecting to be really bored sometime this week, let me know!

    a thousand words: First Sketches

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    With the main browsing UI for a thousand words up and running, it’s time to bore the world with more pointless trivia before moving on. Today: design sketches!

    Pretty much every software project I undertake these days begins with a sketch of the user interface and an initial structure for the database. Labouring under the cruel ‘no whiteboard’ conditions at home (maybe I should get one?), I drew these out on paper. Passing the UI sketch over to Eric after about 5 minutes’ work, she described it as “awesome”. I think that’s the first time that’s ever happened; the general response at work is along the lines of “but where are you going to put giant-ugly-element-X that I’ve just thought of and wasn’t in the spec?”. So that was that, and I’ve coded it up pretty much as it was on paper.

    The database hasn’t changed much from the original design yet, but it will have to soon – as designed, the vote (‘stars’) system doesn’t record each user’s vote on each story, so it can’t support users changing their vote. Sometime during development I’ll have to devote a few hours to figure out the best way of handling it, though that probably comes down to a few minutes as someone on Stack Overflow has inevitably asked about it already.

    a thousand words UI Sketch
    a thousand words Database Design

    Next up on a thousand words is coding the first few forms that will allow users to register and log in, submit photos and submit stories. That should be done within the next few days, and will allow me to play with actually changing the contents of the database, rather than just showing views of it.

    a thousand words: A New Timesink has Arrived!

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Somehow unable to cope with actually having free time of an evening, I have taken on yet another project which will doubtless push me deeper into the dark, untamed wilds of the internet, the land stalked only by the mysterious beast known as the “web developer”.

    Eric has come up with the idea for a fiction-writing community known as “A Thousand Words”. The concept is simple:

    • Users submit photos or other images that they find interesting
    • Every week (or other suitable period of time), one of these is chosen by the site staff
    • Users then write short stories, of around 1000 words, inspired by the picture
    • Users rate, comment etc. on each other’s stories

    I’ll be coding up this site in my spare time over the next few weeks, and you can check out my current progress on the live site at a thousand words.  Currently, the database design is done and I’m partway through the UI of what will be the main page.  My todo list is roughly:

    1. Finish the main page and story page UIs.
    2. Add bare-bones pages for all the GET/POST functions, e.g. registering accounts, submitting stories, submitting pictures.
    3. Test all the functions.
    4. Work on their UIs.
    5. Start closed beta testing for anyone interested.
    6. Liberally apply jQuery to improve user experience.
    7. Add commenting, possibly via DISQUS.
    8. Add proper user profiles, gravatar support etc.
    9. Get everyone I can find to try and break it.
    10. Release!  Open the flood-gates, and despair at the dribble I receive.

    As I go I’ll be posting updates and hopefully-interesting insights here, and you can always check the site at athousandwords.org.uk to see how I’m getting on.