We’ve decided to offer Kids’Player free of charge. Probably was a bad idea to try and grab a couple of cents in the first place, but we wanted to experiment and see how something like this would fare.

Anyway, we haven’t updated the app since its release, even though we got some ideas we’ll be implementing once we find the time. But it’s still a nice little player for kids, especially for audio books and the like, or really anything where skipping sucks. Which of course means that it’s just as great for these famous concept albums you used to enjoy when you were a kid. ;)

Feel free to leave a review if you download and like it.

Thanks,
Marcus

As recently announced, we now also have our first iOS app in the wild.

It’s called “Kids’Player“, and I’d like to take a moment and explain the reasoning behind this app. Because I’ve already gotten a phone call in which the caller accused our app of being unusable… well, whaddayaknow?

Kids’Player has been in private beta testing for the last couple of months, with the test subjects being 2- to 4-year olds. It’s all good, these were private tests and no kids were harmed during the making of this app.

So why make an MP3 player for kids? Simply put, kids love music, they love touch devices, and they love to listen to music on touch devices. However, standard MP3 players are built for people who can read and — more importantly — can keep their hands off the screen for a couple of minutes.

If you ever watched toddlers “using” the Music app on an iPhone or iPod touch, you’ll have noticed how they never listen to one song for very long, and how they constantly manage to wind up in the stranges possible playlist regions you could imagine.

The same kids are perfectly capable of listening to a full album in a CD player, of course.

Now say hello to Kids’Player! It’s a stripped down MP3 player, bare-bones to the fullest, right down to being unforgivingly strict and modal. You can change albums, press play, skip songs, that’s it.

You have to stop a song playing in order to switch albums, and you’re only shown the albums of one particular, pre-defined playlist. There’s no sorting, no search, nothing.

Also, every tap on the screen has a direct audible result — songs play, skip, stop. Compare this to any other player which lets you navigate playlists and whatnot while listening to music. Again, this is for small kids, 3-year olds or so, who can’t even read. They can’t differentiate between playlists and songs, folders and playlists, artists’ names and album titles. It’s no wonder they can’t keep a songs playing: how would they know which tap just moves the screen around and which tap would change the music?

So… Kids’Player.

We had a first, very rough prototype ready late last year and refined it ever since. Most kids just need 30 seconds of instruction, one minute of tinkering around, and if the music’s right, they’ll keep it playing.

It’s nothing spectacular, nothing earth-shattering, just a small app to help kids listen to their favorite tunes. It works great in hand, mobile, and it works great in docking stations.

You can grab it on the iTunes App Store.
Have fun.

You’ll see this branding quite a lot this year. We hope.

We’ve just submitted our first iPhone app to the App Store: Kids’Player. It’s nothing spectacular, just a pretty minimal music player for a small, restricted audience, but still… it’s our first iOS submission, so break out the champagne. (yeah!)

If the review gods find nothing store-shattering, you’ll soon see a button on the product page which you might click (or tap) to rush and download the app for 99 cent apiece. It will make your kids happy, and turn us into insanely rich and famous people. No doubt. So fingers crossed and all, let’s just hope we didn’t infringe on some funny patent someplace or some such some-so some…what.

But wait, there’s more!

This small app — Kids’Player — marks the beginning of a new era here at the Soulmen. It’s a glimpse of our future product portfolio, a portfolio currently dominated by Ulysses.

We’re not abandoning Ulysses by any means. In fact, far from it. We’re just widening our field of play, or rather let you participate in what we’ve been playing with all along.

See, during the course of the last few years, we’ve worked on quite a lot of side-projects, some of which died, some of which are now starting to bear fruit. You might’ve already seen Daedalus touch, our upcoming text editor for iPad. It’s been set back a bit because of the Mac App Store (Ulysses), but it’s progressing nicely, and we’ll have some new screens or even a short demo movie ready next week. So watch this space.

Another project we have been working on for quite some time now, is a new breed of MP3 player for Mac OS X, one that would improve navigation through the sheer masses of songs we’ve all been piling up; I currently have 10.000 songs in my library, and while iTunes is an overall great player and manager, it doesn’t explicitely shine in that area.

This project, called HouseParty, has been around for over five years now, and it has seen various internal alphas and iterations. When we started it, we already designed with touch screens in mind, even though only a few people were using them at that time. When the iPhone arrived, we added remote control capabilities over WiFi, but were struggling with the overall direction the app had taken. Now, with the iPad around, we decided to stop, reboot and move the whole project over to that new device.

We hope to have HouseParty released this summer, and will setup a tiny-tiny preview site early next month.

Then there are some smaller apps in the pipeline, one of which will let you design CD covers for use in iTunes or *cough* any other *cough* music player for that matter. Should be ready in February, available through the Mac App Store.

As for Ulysses? We’ve got a lot in store (no pun) for it, but we’ll first need to sort out that review mess before announcing anything. So let’s just hope (again) that it all works out in the end. And quickly.

So, where do we go from here? Diversity, no focus, or iOS-only maybe? Nope. In fact, we’re more focused than ever, determined to also release apps in smaller steps, smaller packages, and as soon as we see fit. That’s instead of refining, revising and over-polishing for years until we get bored and tuck the code away.

Great times ahead.
Have fun.

This does not sound too promising, I guess, but let me explain. We are having major technical and/or legal problems. All of Ulysses can easily be realized on the iPhone — except one part: Ulysses’ heart. Semantic text editing.

More precisely, the whole problem resolves around on single issue: Displaying styled text while editing it. We need this ability to display the styles, which is the core of our concept. Everything builds on top of it. Apple greatly improved in the iPhone OS 3.2 on what is possible for text editing, however there are still major parts missing. Currently, we see two ways we could do the coloring:

1) The hacky way: We observed that the text editing view in iPhone OS is actually a web view. A web view which edits and displays HTML. HTML which we can get access to. Access we can use to modify the structure and styling and hence add colors, etc.
The Problem: Private API. Each of the steps I just described is private API. And you know what that means. Bummer.

2) The legal way: New to iPhone OS 3.2 is an advanced text rendering engine, CoreText. This does nothing but display text, but it does it well. And there is the ability to directly grab the keyboard input.
The Problem: All the rest. We would basically have to re-write ALL user interaction! Text selection, text loupe, copy and paste, spell checking, etc. All these things are missing. Even worse, while we could eventually implement all of these, we will never be as sophisticated as Apple. I bet they used a couple of man-years to implement this stuff, no power we have. Ulysses would always feel like an alien on the iPad. If you know the level of quality we require from our products, you know that we’d never go for such a solution.

And this is the mess we are in. We have – right now – an implemented working version of the first approach. We also have an implementation of the second one – except of all the nice user interaction you’d naturally expect. I will be going to WWDC next week and talk to some guys at Apple. I hope they will have good news for me, but I’m afraid they won’t.

We would sooo love to do Ulysses on the iPad. 1) is that Apple would not let us, 2) is too much effort for producing average results. We know no other way. Let us hear what you think! We’d like to discuss this issue with you!

The Soulmen

Here’s what we got so far, in no chronological order: Paragraph styles, inline styles, user-definable start- and end tags, user-selectable font colors, add/edit/rename/remove styles via project prefs, project-specific style settings (YAY!), styling while typing, styling when editing.

Here’s what you’ll get with 1.0: All of the above plus highlighting with user-selectable color, selection styling (select text and apply style), full style editing from within the editor.

Max really pulled it off. Not much more to add.

Today I was skimming through a bunch of iPhone mockups on my desktop and rediscovered some old app concepts. They’re mostly minimal in nature, and if we had the time and resources we would just code them up and try to release them on the App Store for free.

Well, we have neither, so I decided to share some of these ideas on this blog rather than trying to catch a new coder and convince him to create non-profit two-minute distractions. ;)

So here I go, first up: The Good Vibe.

Concept:
The main idea is an app that you launch when in a hotel room or before going to bed or during an expo in a strange town in the middle of nowhere. You launch the app and can sort of “see” the current vibe of the city you’re in, or check the current vibe of your hometown.
You can also leave a message right where you are, such as “feeling lonely” or “love you all”, effectively tuning the vibe of your location.
It’s a bit like walking the streets at night. Cars passing by, people rushing to get home. A small nod or a smile from a passer-by can make all the difference; about the way you feel — about the city, about your current situation, any situation.
That’s what the app is meant to do: Make you feel good, sort of. Connected. Not alone. At least put a smile on your face. If only for a second.

Operation:
The app collects your geo location and presents you with a view of anonymous short text messages written by users in your vicinity. At a timed interval, one of the messages gets highlighted and enlarged, then another one, and another one and so on.
There’s not much interaction here — you just see a bunch of messages and a single one highlighted. You just watch as messages fly by.
You won’t be able to swipe over the view and activate other messages or such. But you will be able to send your own messages. These will be added to the stream of your current loc, so other users can read them.

Ratings:
There’s a “negative” rating option when sending messages.
There’s also a “negative” rating option somehow attached to each highlighted message. This might be a simple “-” button or a top-to-bottom swipe gesture (especially if we want to fine grain the rating).
The ratings have no effect on the messages’ display or such, but rather on the city the rated messages were sent from.

Effects of Rating (1):
Ratings are sent to the server and collected in order to define the “vibe” a city is in. Unrated messages are counted as “positive”, while negative ratings are counted as such. The +/- ratio defines the city’s current vibe.

Effects of Rating (2):
The background color of the messages view changes depending on the city’s vibe. A positive city might be vibrantly colored and even have a slightly pulsating background, while a more negative city displays a darker message view.
A double-tap or such will open a world map which somehow shows the current vibe of select cities. You’ll be able to check out the vibe of all cities, but you can only activate the message view in two core locations: Your current loc, and your hometown.
The idea is to create a somewhat strong connection between you, your current location, and other users in that location. Every message you send has an effect on the vibe of your location. So even more than just checking out the “vibe”, it’s about creating a vibe. You’re part of the city, so to say.

Features:
Send short messages to a server.
Receive short messages based on geo location.
Option to rate single messages as “negative”.
Map of world with select cities showing “vibe” (based on negative ratings).

How to:
When the user connects to the server, we check the geo loc. We then simply use a very fuzzy method of finding messages in the vacinity. If he’s the only user within reach, we simply use a wider radius or the first larger user base.
We then push a fixed amount of messages to the device, let’s say 30 to 50. These messages contain the amount of positive/negative messages based on the loc’s computed vibe.
The messages get displayed in a very minimal style to create some sort of zen-effect.

Message selection:
Depending on how active the user’s area is, we might have trouble finding enough messages to display. So we’ll need methods to compensate for inactive areas. These methods may include a smaller selection of messages (only show 10 if the area is very inactive) and/or a wide scan radius in both geo loc and timeline. E.g., we could simply check if it’s the user’s first time around and then push the first 20 messages instead of the latest, then simply include 10 arbitrary NEW messages from all over the world.
So even if the user checks the app in a location where nobody has ever left a message, he will get 30 messages, most likely in the correct language, and in the current vibe, which will always be “good” since there’s no negative input from there and so we only push good (or rather: neutral) ones.

Infrastructure:
I don’t know nothing about server load, latency, geo location troubles and the like. I don’t even know how to get the data into a database, let alone how to structure it in order to efficiently push 30 short messages to what might be 10.000 simultaneous connection attempts.
I simply don’t know how to pull this off. :)

Closing comment:
I think this might be fun, if only for a few months or so. I think that the social aspect might take off, especially with cities being labeld as having a good/bad vibe. Just imagine having Rome displayed in devilish red while London gets the love…
However, this might be a complete failure, with only 10 users active and all of them posting links to illegal downloads.
Given our current size an structure, we can’t even give this thing a shot, so we’ll leave it as is and probably just bury it.

And that’s it. :)

I’d still love to see this materialized somehow, so if anybody is reading this and wants to pick it up — feel free to do so.

The above is a screenshot of a recent build of Ulysses Mobile. The semantic editing depicted here works just as it does in the desktop version — paragraphs get colored automatically based on a prefix.

Problem: It’s a hack. So take it as a proof-of-concept.

We’re quite exited, however.
(it works! it works!)

When I started work on Ulysses Mobile, I wanted to create a stand-alone writing application for the iPhone/iPod touch. It may have had basic compatibility features with its bigger desktop brother, but I didn’t think of a 1:1 port of Ulysses 2.0 to the small screen.

I wanted to create a writing application tailored to the iPhone, and not just an iPhone conversion of a desktop app.

Of course, I also thought it couldn’t be done anyway. Filters, multiple notes, projects, bookmarks, full-fledged semantic editing with markers and stuff — impossible. Add syncing to the mix alongside Ulysses’ (desktop) system of keeping open and saved versions of each document, and you have an untamable beast of complexity; and uselessness.

See, while I strongly believe people want to write larger texts on the iPhone, I also believe nobody wants to wade through 20 different screens just to annotate a certain part of a chapter on his ride home.

So I set out to create just a nicely working multi-document editor with limited semantic abilities and a single note attached to each of the documents. No syncing, and none of the more advanced an/or complicated features such as filters or multiple notepads.

I started at the document edit screen and let the application grow around it. And as I went along, revising the interface for that simplest of apps, finding homes for the few things on the feature-set, more and more useful stuff kept popping up, which just seemed to fit perfectly well not only into this new app, but also into the goal of creating a great iPhone editor AND staying true to the Ulysses way of doing things.

Interestingly enough, I found solutions for lots of things I thought wouldn’t work, because they — at first — looked inappropriate for the device. Previews are such an example, as are multiple collapsible notes.

I didn’t set out to create previews and multi-notes. Instead, it just happened that I added functionality that, by chance, just mimicked a desktop feature perfectly. Of course, these features ended up at unfamiliar places, but that’s not a problem at all. Not for me and, most importantly, not for the user.

What I have now is the complete package. Groups, Collections, Filters, Documents, multiple Notes, Project Notes, Excerpts, Counters, Status, Labels, Timestamps, and of course Inline Styles, Paragraph Styles, Markers and Bookmarks. Even Style Jumpers. And, yes, multiple projects on the iPhone with item-specific syncing via USB and WLAN.

Easy to use, optimized for the touch screens, clear and simple in design and user interaction.

So while the first idea of Ulysses Mobile was to create a fairly basic but highly optimized application, it soon grew into a more or less 1:1 adaption of Ulysses 2.0 to the small screen.

Goal accomplished by missing it for miles, he.

But… I’m just the designer, and all I have today is every single screen in PSD format, waiting to be re-imagined in code and distributed as a stable running executable.

Estimated timeframe: Roughly six months for a beta given what else we have in store.
Not viable. Not at all. At least not right now.

So while Ulysses Mobile will happen eventually — yeah, the real deal, the big, feature-complete sync-em-all thing we’re all dreaming of WILL happen — we forced a full stop on the project, sat down and re-thought the initial version of Ulysses for the small screen.

Starting once again at the editor, and letting it grow from there, ever so slightly.

Today, we froze the feature set. We might still be weeks away from a distributable beta, but we’re talking weeks, not months.

We believe that what we got will be of great use for existing users, as it will be of great use for iPhone users looking for a versatile text editor on the go. It will be a stand-alone version, as well as a companion for Ulysses 2.0.

Excuse me, 2.1.

Given the nature of iPhone development these days, I can’t disclose much more than what I already did. And I need to get back to work. There’s an icon waiting to be tapped.

One thing to keep in mind when designing an interface for the iPhone: Physical size vs. pixel accuracy.

For the desktop, you can pretty much design an interface based on what you see in Photoshop. If you can barely position your cursor over a button, or if the text is too small to read at 100%, that element really is too small, mind you. If it works at 100%, however, it mostly works for everybody else, even for those crazy types with their 30″ screens.

For the iPhone, however, what you see in Photoshop is almost two times larger than what you will get on the actual device. And to make matter worse, not all fingers are as small, tiny and accurate as that black’n'white arrow pointer we all know and love.

In other words: That iPhone is one damn small device!

The above picture shows the difference in size between the 480×320 screen (back) and the phone in 1:1. Your mileage may vary, of course, depending on actual size and resolution of your computer screen; mine is an iMac 20″, and the phone clocks in at about 60%. Have a look at the picture in full size.

It’s easy to create seemingly perfectly sized items that end up way too small on the device. Be it info-buttons or gesture pads. It’s a trap, really, as you could work for hours on a perfectly laid-out screen and still end up with something totally cramped.

One tip I have is to have a second view of the interface open at all times, zoomed out til you get a 1:1 view. That’s if you don’t mind a bit of grease and smear on your screen, hehe. You can then design at 100% and sort of try it out in 1:1 without having to transfer screenshots via iPhoto or some such. teehan+lax’ iPhone GUI PSD is a great place to start, btw, though I don’t use it as much now as I did a couple of months ago.

However, I find myself more and more going back to a drawing board, literally. In fact, I just bought a set of small notepads which perfectly fit into a tiny leather case. I then cut out a cardboard the size of the iPhone’s screen. This serves as a 1:1 stencil for quick sketches on-the-go as well as a pretty decent test of touch areas.

Have a look:

The notepad/leather case combo has approximately the weight of my iPod touch, and the overall size comes close also. I can scribble on paper and still have a decent tactile feedack. Funny as it may sound — it’s almost as if I would prototype the interface on the device.

What’s interesting is how small the mockup-screen looks on paper when compared to the real thing. The first few days I had to double- and triple-check if I had used the correct cardboard, beacause I always felt like “it just can’t be that tiny”. But it is.

This ends my chatter for today. Got some work to do.

I’m not buying it (haha), but if it’s real, it’s certain to stir up some heated debate. After all, it wasn’t EA or Konami or SEGA who made the AppStore into what it is right now — it was the likes of Demiforce and ngcomo, IIRC…

[via]