Back in July M Cubed started offering design services. This was meant to be an alternate revenue source to our software that we could rely on. Unfortunately this didn't turn out to be the case. While technically M Cubed is a 2 man operation, it is in reality a 1.5 man operation as Fabio has a separate day job.

Having a day job and then coming home and working nights and weekends leads to a person being worn out very quickly. A lot of our design work was being delayed due to Fabio not having the time or energy to do work and this was also filtering down into design for our products. Minim 2.0 was originally planned for a late november release, but delays in design related stuff meant it kept being pushed back.

The delays meant that the money coming in from design wasn't really worth the effort, and I was unable to help as I'm not exactly icon designer material. This has meant we have had to make the decision to stop offering graphic design services. While we were able to deliver what we hope was high quality products, circumstances meant we weren't able to offer high quality service. It is better to not do a job at all than do a bad job.

While we are stopping our graphic design services, we are introducing two new design services where we can offer a high quality of service as they are areas of design I am able to handle myself: Usability and Accessibility.

There are many services available to Mac and iPhone developers for graphic design. A quick google search will bring up pages of people offering icon or UI design services. But there are very few services that focus purely on usability and none that I have seen that focus on accessibility.

So what will our usability and accessibility design services entail?

Usability

Well in a nutshell, you give us your app and we will pick through the user interface and point out any areas where usability could be improved. We will explain why things are in need of improvement and what items are urgent.

Of course, there are different degrees of usability. You can make any user interface usable, in the sense of doing what the user expects, by following a series of rules. But usability can also be about how a user feels when using your application. Is it just functional or is it enjoyable? Our usability reviews will provide suggestions for areas where your user interface can be re-thought to make it highly enjoyable as well as functional, turning a user who is merely happy with their purchase into one who raves about your app to their friends and co-workers.

Accessibility

Our accessibility reviews will work in much the same way. We will go through your application and highlight areas where accessibility is lacking and give you details on how to fix them. But we are also going to do something a bit crazy. We will also show you how to find and detect the majority of accessibility problems yourself.

"But surely that is what we're paying you for? What is the point of us coming to you if you're just going to tell us how to do this work for free?". Very good questions. The fact is that 90% of all accessibility work is trivial. While I certainly am not opposed to you giving us your money, I believe that it is ultimately a waste of your money and of our time to keep coming to us for help with trivial matters.

What you may need help designing is the non trivial matters. How do you make a custom control accessible and what should the interaction model be for disabled users? What is the flow of my application like for disabled users? In a way, if our usability design is aimed at abled users of your software, our accessibility design is the exact same thing but for disabled users.

Getting an estimate

So how do you procure our services? Send us an email with details of your needs to design@mcubedsw.com and we will get back to you with an estimate of how long we think it will take. We charge an hourly rate so this will give you a good idea of how much you can expect to pay. So get in touch and start getting feedback on the accessibility and usability of your apps today!

(0) Comments

As with most things in life, there are two opposing schools of thought when it comes to software. When it comes to the size of things you can either go big or small. Is your app going to have a large scope or small scope? Is it going to target the general market or a particular niche?

When I started work on Code Collector Pro 1.4 over the weekend I was confronted by the issue of whether to go big or small on two key points: the size of updates I release and the size of the classes I write. These are key decisions that affect all the software we write, so it is worth deliberating over them. Now these aren't questions I've only just asked, they are ones I've looked at continuously and am only just starting to set myself on.

Release sizes

There are two extremes to software release size. At the large end of the scale are products like Adobe Creative Suite, Microsoft Office and Apple's iWork and iLife suites. They have a release roughly every 1-3 years and they feature large updates to several applications. At the smaller end of the scale are products like WebKit or Adium, where small releases are made every day in the form of nightly builds.

Most Mac devs go for the middle ground of this, releasing several medium sized updates a year, though what constitutes a "medium sized" update varies widely. I've been striving to reach the smaller end of the scale with little success until now. The combination of full time education limiting coding time, and a lack of discipline when building releases has led to a series of sporadic releases that are quite large.

With Code Collector Pro 1.4 there was a long list of features building up. There hasn't been a release for 14 months and the featured planned involved would take a good 3-4 months to complete. The release eventually included a UI overhaul, new sharing features, syncing and a re-written syntax highlighting engine.

So I opted to break it up into smaller releases. The UI overhaul is a collection of many small changes and some under the hood changes and nicely separates into a different release. Sharing improvements and syncing were the two major features I wanted for 1.4, so these would fit nicely into a second release. And the syntax highlighting improvements would also fit nicely into a small release. As such the large 1.4 now became much smaller versions 1.4, 1.5 and 1.6.

The current plan is to work on 1.5 straight after releasing 1.4. But why not then combine them? Well there are 3 main reasons not to:

• Syncing and sharing will take 1-2 months to implement, but the UI improvements can be done in a few weeks. As they are the low hanging fruit I would most likely do them first. So why have those improvement sitting around on my computer for a few months when I could ship them to users?
• Smaller releases often lead to a better feeling of productivity. You do have more time taken up by prepping for release, but you feel like you are getting somewhere much faster. It's easier to climb up a set of stairs than a cliff face.
• Releases = money. Whenever you make a release people see it on download sites and news sites. This leads to people downloading the app and then ultimately buying it. The more people buying your software the more people spreading word of mouth advertising and the more sales you get. Ultimately each release is an extra boost of energy into a positive cycle.

Class Size

For those of you who aren't programmers a brief explanation. A class is a unit of code. It contains data and actions upon that data. While not always true, generally a class = a separate file of code. As with release sizes you can either have a few large classes or lot of small classes. Cocoa provides ways to help you divide your code up. Code relating to windows goes into Window Controller classes, code relating to any documents goes into your Document class.

Prior to OS X 10.5 there was a missing piece of the puzzle though. While you could easily split up your application into windows, it was harder to split up these windows into individual views. Then in 10.5 Apple introduced NSViewController, which made this task easy. This means you can split your UI up into even small classes, which leads to easier to maintain code and more reusable code.

As an example, these are the window and view controllers that make up a typical screen in Minim:

As you can see, this one screen has 4 main components. The window, which contains a sidebar and an info panel, the latter of which contains the current tab. Each of these is coded in a separate file. This means that if I need to edit something to do with the sidebar I open the sidebar view controller's file. It also makes things more re-usable. There is a file that contains the file manager view controller class. This same class is used for songs, podcasts, albums and shows.

Now Minim is build with Leopard in mind. Code Collector Pro however is very much a Tiger era application in its design. This is what Code Collector Pro's main window looks like from a class point of view:

There is one class that manages the window, the sidebar, the snippets list and the code view. It even controls the inspector panel. At 2420 lines long it is the second biggest class in any M Cubed app, beaten only by the class that talks to Lighthouse in Lighthouse Keeper. That over 3 times the size of the biggest class in Minim.

Now while a large class isn't necessarily a bad thing, a large class that does lots of different things is. If I want to edit something to do with the sidebar in CCP I've got to search through 2400 lines of code to find what lines are relevant, compared to Minim where I open a file where all the lines are relevant.

I'm currently working through the process of breaking up this monolithic class into much smaller, more manageable chunks. I've already managed to split it into 7 classes, I may be able to divide those even further. Ultimately though, this will add nothing new to the application. It will work exactly the same as it did before. What it does do is make it easier to add new stuff in the future.

It's How You Use It

So does size matter? Well as the title of the post suggests, it does. But what is a good size depends on many things. To quote Albert Einstein, "Everything should be made as simple as possible, but not one bit simpler". You should strive to make things as small as you can, but not unnecessarily. While I can break one large class up quite easily, another may not break up. It may be the case that it is already as small as it needs to be.

The same goes for releases. I can split up what was going to be CCP 1.4 into 3 different versions quite easily, they logically split up. However, Minim 2.0 couldn't have been split up. It was a large project, but it couldn't have been made any smaller. Everything has its size, the job of anyone creating something, be it a piece of code, a product or a business, is to find the right size.

(3) Comments

After 6 months of work, 20,000 lines of code, and countless amounts of blood, sweat and tears we are happy to announce that Minim 2.0 is finally available. It has been a lot of work and involved learning quite a lot but I feel it has been worth it when you see the finished product.

It now requires Mac OS X 10.5.8 or higher to run (previously it only required 10.4 or higher) and now costs €25 (around $36). You can find out more about it at minimapp.com

From 1.0 to 2.0

Minim 1.0 was released over 3 years ago in November 2006. Since then it received just 2 updates, version 1.1 and 1.2. It suffered right from the start from my inexperience, not only at coding, but at creating a product that can sell. Since then I've released 2 successful products and become a much better developer.

So when it came to working on Minim 2.0, it made sense to treat it as an entirely new product. I used the experienced I'd gained over the past 3 years and re-designed and re-coded it from the ground up. I added some new features that weren't in 1.x and took several features out that weren't particularly useful. I made sure to justify everything that went into the app, rather than just saying "Well that would be cool" as I did with 1.x.

It is also the first app I've worked on that had designers heavily working on it. This has been an interesting experience, as it involved doing a lot more custom UI elements than any other app. It also meant the release schedule wasn't just in my hands as well.

The result is what is quite easily the best application I have created to date. It is a sign of things to come from future versions of Code Collector Pro and Lighthouse Keeper, as I'll be able to give them the attention of a full time developer.

Accessibility

Last year I made a pledge about accessibility, that I was unfortunately unable to fulfil. Lighthouse Keeper and Code Collector Pro are 90% accessible but not the 100% I was aiming for. But Minim represents an important step in the direction of making all M Cubed's applications fully accessible. It has been extensively tested and features several unique features that mean it provides as good an experience to disabled users as to fully abled users.

The lessons I have learned from making Minim 2.0 fully accessible will be invaluable to making Code Collector Pro and Lighthouse Keeper reach that goal as well. I'm hoping that by the summer I will finally be able to say that all of M Cubed's apps are fully accessible.

Open Source

Over the next week I will be releasing various open source components, as well as improvements to existing ones. All of this code comes straight from Minim. I will also be sharing a lot of the lessons I've learnt while developing Minim, so keep an eye on the blog as I get into the nitty gritty of the redesign, responder chain hacking and a detailed look at the drawing code behind the recording view.

(0) Comments

Well, it's exactly 1 year since the last time I posted the M Cubed birthday retrospective, so I guess that means I need to do another one today. The past year has been quite an eventful one, at least behind the scenes.

Finishing University

The bulk of the last year was taken up with finishing my degree. This is the primary reason that you haven't seen much activity from M Cubed the past 12 months. Exams, assignments and my dissertation all took up the majority of the free time I had.

Unfortunately both getting a degree and running a software company require a lot of mental input and it's hard to do both at once. Effectively M Cubed was shut down for several months while I focused on my degree.

In mid June I had my last exam, all my assignments and my dissertation were handed in and I was finally free of full time education. In July I went back to pick up my degree at my graduation ceremony and now I the £20,000 piece of paper that says I am a Computer Science BSc. So with all of that out of the way I could finally focus all my energy on M Cubed.

Going full time

Last year I said that I hoped to be working full time from M Cubed. This year I can say that I am now a full time indie developer. Granted this is helped in part by the fact that I've been able to move back home with my parents and that I'm able to keep my expenses down. Many people wouldn't be able to live off what I'm earning, but it is enough for me to dedicate all my energy to it.

The biggest benefit of going full time has actually been having free time. Previously I would fill my free time with M Cubed work, but when combined with school/university work this would lead to me getting burnt out pretty quickly. Being able to focus most of my attention on M Cubed, I can now use my free time for things that are actually relaxing. I'm no longer having to stay up until 2am coding, I can get offline at 10pm and spend the rest of the night relaxing. I can't emphasises enough how much doing this has increased my productivity.

2 > 1

Going full time wasn't the only major thing that happened with M Cubed this year. As was announced in July, M Cubed's employee list doubled. Fabio joined to help with design and coding. The result is the website design you see now, plus many graphic improvements to our applications that you don't see yet. In fact you'll see the first fruits of our labour next week when we release Minim 2.0

Minim 2.0

Minim 2.0 is going to be the first release from M Cubed since I went full time. Minim has long suffered from a lack of focus and development time. The last release was 18 months ago and only fixed 1 small bug. The last major release was over 2 years ago.

Version 2.0 changes all of that. It has been completely re-designed and re-coded from the ground up. It is practically an entirely new application, the name and the core purpose of the software being the only things shared with 1.x. Whereas Minim 1.x was only the second real application I had written, Minim 2.0 builds on 5 years of experience, meaning I can say with confidence that it will be the best application we've ever shipped.

It really is a shining example of what the changes this year hold for the future. Every release I've done in the past has been limited by the amount of time I've had and has had me as the primary designer. Minim 2.0 has had several people working on the design and we've been able to put a lot of time and effort into polishing it. Whereas before the question was, "how can this feature be added in the shorted amount of time?", the question is now, "how can we best implement this feature?"

Accessibility

The other thing that Minim 2.0 will showcase is accessibility. Earlier this year I made a pledge: "By the end of 2009, every application I produce will be fully accessible". Unfortunately I won't be able to fulfil that pledge by the end of 2009. However, the next major version of each application will fulfil the pledge of making every application I produce fully accessible.

Minim 2.0 does fulfil that pledge by being the first M Cubed app to be fully accessible. We've put a lot of effort into achieving this and we hope it will help in providing a first class experience for disabled users.

Code Collector Pro is mostly accessible but needs the most work and this will be fixed in version 1.4 which we hope to have out early next year. Lighthouse Keeper only has some minor accessibility issues but these will be fixed in version 1.2.

To further highlight our emphasis on accessibility, we are setting up a new email address where you can contact us about any accessibility related issues with our software. If you have any questions about our the accessibility of any of our products then send us an email at accessibility@mcubedsw.com

The year ahead

Well the next year will see a lot more activity from us. As I've already pointed out, our next 3 releases will be Minim 2.0, Code Collector 1.4 and Lighthouse Keeper 1.2. We also have plans for a major revamp of codecollector.net, which has been feeling a bit neglected. We'll also be looking into dipping our toes into the pool of iPhone development. And to top all of this off we have a number of open source projects we will be working on. All in all, the next year will probably be the most productive one in M Cubed's history. Hopefully the post a year from now will tell you about all these great projects as M Cubed celebrates a half-decade of existence.

(2) Comments