The reason that I've created this "incubator" forum now is because I recently been corresponding with an other developer (Bleicke Petersen) who like the way that I build my apps and ran my buisness. He wanted to do an internship, but I'm not setup for that and wasn't sure that me assigning him work would be very useful. So instead the idea is that I'll "mentor" (in quotes because I'm really not smart enough to be a mentor) him as he goes through the process of building his own app. The goal is that you will eventually see the results of this work up on the Hog Bay Software site as a new application. Success certainly isn't guarenteed, but I hope it will be a fun and useful process.
So to start things off I've excerpted a our emails so far. Future discussion will happen in this user forum. The goal being that if the app reaches completion the entire process will be out in the open and documented so that someone else can follow the trail. And of course everyone is invited to jump in on this converstation and make their own suggestions.....
Excerpted email correspondence to date:
Jesse says...
Maybe we are looking at this from the wrong perspective. The whole "internship" think is a little scary to me. It's a fairly big risk for both of us since I'm not a big company that's setup to handle interns.
What if instead we called it a "mentorship". The goal is for you to produce and sell a shareware application. We could start that process remotely right now with very little risk.
Bleicke says...
That's actually a great idea :-)
...
Ahem. Back to the app I want to build. This should actually be part of TaskPaper, I think. Here goes:
This is because I really need a calendar. I forget things. BUT: iCal takes too much time. If I have to spend 30 seconds to enter an appointment or look one up, I'm not going to do it. This is why I have a textfile on the desktop called "Termine" (german for appointments), right next to my TaskPaper "To Do", in which I have one line for every appointment I have to go to. That is easier to use than iCal.
So this would be like TaskPaper, but instead of storing the information in a textfile (which is a great idea btw) it uses the iCal on your computer. What I see as kind of a problem: This should be IN TaskPaper. Not a separate Application. Maybe we can build this and later merge it into TaskPaper?
Jesse says
Great idea, in fact this is a program that I've been wanting to write myself. And it might make sense to make this part of TaskPaper, but for now lets think of it as a separate program... that way you'll be responsible for everything, not just building onto an existing project. I think it will also give your more flexibility to create the "perfect" solution, instead of making compromises so that your solution fits in with TaskPaper's way of doing things.
That brings up a first reading assignment :)
http://www.paulgraham.com/marginal.html
Also check out these books.
Also describe your product using this template.
Bleicke says...
I think I like the name rasCal :-) He's the little angry guy who makes you do things.
For people who forget appointments and think iCal is too complex to just write down a date or see what's coming up, there's rasCal. rasCal is a small calendar that lets you write down dates like on a notepad, but stores them in iCal for you. Unlike iCal itself, you do not need to open a big application and press a lot of buttons. You just write down the date and what to do. Yet you get all the benefits of iCal, because the dates are entered into your iCal database, letting you use it with all your applications tailored for iCal. And if you want a quick look at what to do next, just open rasCal and see your next appointments come up on the list.
I hope that gives me (and you, and the "customers") a clear message of what the app does.
Jesse says...
It's a good start, but write it in the journal because I think in the end you'll be surprised at how much changes over time... lots of room for improvement I think :)
First the name isn't bad until you do a google search for "rascal". Opps... I try really hard to make my product names unique, or near unique for google searches. That makes it much easier for people to spread the product via word of mouth, podcasts, etc. It also makes it easier for you to keep track of what people are saying about it (such as via google blog search, or technocreti (technocreati... another bad name in my opinion because i can never spell it!!!). So I would rethink the name. Generally I've been trying to smash two descriptive words together...
WriteRoom TaskPaper
I I'd like to keep with that style when possible. The nice thing about this naming pattern is that you can usually come up with something that's google unique and it also makes it easy for a potential user to understand what your app does by just reading the name. So maybe try to come up with some descriptive words and then go to http://thesaurus.reference.com/ until you can find a pair of words that work well together and is google unique... it can take a long time!!!
I think that your description is ok, but too long. Again "Small can be perfect"... your goal is to explain what your app does as quickly and accurately as possible, so that people who need your app will read further and people who don't wont become unsatisfied users. So take your first sentance:
"For people who forget appointments and think iCal is too complex to just write down a date or see what's coming up, there's rasCal."
It contains the right info, but it is not focused enough. As soon as you start adding "or's" in the text I think you start to lose the reader... the user thinks "is rascal best at writing down dates, or at seeing them... what about this other competing calendar program.."
So here's my take on a first sentence...two options... I'm sure it can be improved upon too...
"For iCal users who want a faster way to work."
Your app is meant to integrate with iCal, so iCal users is who you should target. Your goal is to make working with iCal faster.
So that's my take on things. I'm pretty confident that I'm write here, but I'm also not a particularly good writer, so who knows. I would suggest you check out this book:
http://www.amazon.com/Style-Lessons-Clarity-Gra...=pd_bbs_1?ie=UTF8&s=books&qid=1196613359&sr=8-1
I really wish that someone had forced me to read it in 8th grade about 10 times. I have to say that I've never really got more then half way through it, but the opening chapters really helped me to simplify my writing and get to the point. I highly recommend it, I just wish that I naturally followed it's advice more often... For me it takes lots of time and editing to simplify things.
Bleicke says...
Phew, coming up with a unique name is not easy! I just checked all my ideas with "something that sounds fast" + "Cal" and they were all taken. The closest one is "HotCal", but it doesn't really sound fast. Only in a "drop it like it's hot" (drop ist FAST) sense. Hmmm. Need to think more on that one. (new positioning statement)
HotCal is a quicker way of using iCal. See all your appointments in a glance and edit them on the fly! Do you like to organize things in iCal but find it inconvenient for daily use? Then HotCal is for you!
This time I made it shorter. What do you say?
Jesse says...
Yeah, names are a big pain, but in the end a good name is important. But you don't need to think of it right away, or before you start your project. It's just something to keep mulling over in the back of your head. I think "HotCal" is better because of it's uniqueness, but I'm still not sure that it's a good final name... generally apps with "hot" in the name seem like they are trying to hide something to me... but don't worry about that for now, "HotCal" is a fine working name.
This time I made it shorter. What do you say?
Better because it is shorter, I never did really read through the last description :). But I still think it could be improved by following the positing statement "template" a bit closer. In the above it still sounds like you are trying to sell me something with sentences like "Then HotCal is for you!". I think the software should sell itself, you're goal with the positioning statement be to give a precise description of the software and why the user might want it. Later on the product page you might make things sounds a bit more salesly, but the positing statement should stay clean.
Here's another idea for a positing statement...
"For iCal users who want a simpler way to access their calendar data. TextCal provides quick access to your iCal events through a simple text based interface. Unlike iCal TextCal is light weight provides a faster way to add events and see what's next."
For an example of how this text might be used check out this recent blog review of WriteRoom. (By the way I found that review via this search http://blogsearch.google.com/blogsearch?hl=en&a..., so the reason that I'm aware of it is because WriteRoom is a unique name)
http://www.thingelstad.com/2007/12/stay-focused...
Note that after the first two paragraphs they quote the positioning statement from the WriteRoom page. So that's the kind of place that your positioning text might show up. It should be able to stand completely on its own.
Anyway I think we've done some good thinking on the name/positing. It's something to keep thinking about in the back of your head, but its probably time to start focusing on other things. Most important I think is the text format of the data. Do you have any ideas for that yet? Are you a unix guy? I'm not really, but you might look in the unix command line world for some good ideas for text formatting a calendar. Or if you can find them look back to older dos calendars. Old abandoned computer programs are a great resource for ideas when building text based interfaces!
Copyright © 2008 Jesse Grosjean. All rights reserved.
Bleicke - December 10, 2007 11:25 PM
The date format could be interesting: Every country has their own date.
For example, being a German, I'd type for today:
Mo 3.12. - 10:00 - Meet Thomas for XML
Because it is Monday, the 3rd of December and the appointment was at 10 AM. You might type:
21/03/2007 - 10:00 AM
I don't type the year, because my appointments are all in this year. But what if someone has appointments for next year? It's only one more month after all. Also there might be 1000 different date formats. I'm not sure how this is handled on Mac OS X. I was very positively surprised that the Mac is able to put my German date format into almost all applications by default. But I don't exactly know how that is handled.
It is easier and more intuitive if the app just recognizes your local date format. Having the user configure it is not cool. But manually recognizing all the different date formats would be extremely error prone and not very elegant either.
What about the day of the week? I always type that because then I know which day it is without having to look at the calendar (which would cost me the time I just saved).
The auto-recognition will probably be very tricky, unless there is something provided by Apple. I'm not deep into Cocoa enough yet to stumble upon that.
Bleicke
reply | edit
jesse - December 11, 2007 1:38 PM
I was thinking...
We had been talking about this as a TaskPaper style "text" ui. I'm not so sure if that's so important for this app. The main selling point to this app is that it provides a "smaller" faster way to access your iCal events. If we define an external format then it complicates things because you need to start to think about "synching" you text format with iCals data.
Instead I think it would be smarter to forget about the text ui for the moment. Instead just build a NSTableView that displays a live list of the events in your iCal ordered by date. This would always be a realtime view of iCals datastore, so you shouldn't need to worry about synching. And since you will be using NSTableView you also don't need to worry about text parsing, date formats, etc. It really simplifies the problem.
Try creating a new NSTableView that gets populated with events from the calendar store framework and see what it looks like.
http://developer.apple.com/leopard/overview/cal...
Does that make sense. Does this seem compelling to users? The thinking is that for many people a full calendar style view as provided by iCal is to cumbersome. In particular it make it hard to create new events because you must go navigate to the day that you want to add the event on. Same with looking at existing events, you are forced to navigate through the calendar UI to a certain day to find that event.
The solution that I'm thinking about would solve those problems, all events would be listed in front of you in a single list ordered by date. When creating a new event you would just enter the date when it would happen. This takes away the navigation problem.
Thoughts?
reply | edit
Bleicke - December 12, 2007 8:10 AM
Hmmm.
I think there's a little problem with that - it's only THAT little bit faster to use than the actual iCal.
Using iCal:
Apple-Space, type "ical", hit enter, loads immediately on my MacBook. Then click "month" and double-click the target date. Double click the right time, type away, close iCal.
OurCal:
Apple-Space, type "ourcal", hit enter, loads immediately. Click "New Event", somehow select day and time, type away, close.
Even if we find a perfectly fine way of letting the user enter a date, it's still only ONE click faster than using iCal. That's not enough, I think.
Using the text-based interface of TaskPaper is a great advantage over similar products for me. Big enough to make a difference and therefore to pay. But if we only save the user one click, but have a very similar style of displaying the events (it's still a table used with clicking, just not a fancy iCal-table), I don't think it will give people enough benefit.
For "just viewing upcoming events" there are lots of great widgets, the new Calendar widget in Leopard even lets you view upcoming events. So there isn't much of a benefit either.
On the other hand you're right - finding a suitable text-interface may be too complicated. Too complicated for us to make and too complicated for users to get used to.
Maybe it's time we think about another project. We thought this one through and with your new thoughts on this it seems less and less helpful to me. I just tested the time I need to add an iCal event and I can't think of a click-and-play way to make it much faster. It would still need one or two clicks, and iCal isn't that much more complicated. If we don't go for all-text, the benefits will me marginal. And all-text may be unsuitable for entering dates, as you pointed out.
So what do you say?
reply | edit
jesse - December 12, 2007 12:25 PM
I still think there is a lot of value here...
In your sequence you were creating an event for the current month. If it's a different month then that's more clicks. Maybe as a test try entering the birthdays of five of your friends.
Also, while powerful, the visual calendar metaphor doesn't always map well to events as they arrive in your digital world. For example an event might arrive via email in the form "lets have lunch next thursday". In iCal that means you need to navigate the grid view to find the right time... maybe it doesn't seem hard, but for me I always feel a bit overwhelmed when trying to locate a date in the grid view.
With your replacement you would use a table view to display the list of events. But you should use cocoa natural language processing (you mostly get it for free) for dates to enter the date value as "next thursday". And the above scenario becomes much easier. (you would also provide a popup calendar option, but the text option would be available.
Generally I think that for many cases events are more important then dates. The iCal interface is date centric, before you do anything you need to create select a date first. Your app would be event centric. You create the event, then assign extra's like dates, times, etc. This seems like a small difference, but I "think" it would lead to a fairly significant feel to the program.
I still really think this idea is a good one. As a cocoa learning test, just try to get events into a table view... don't worry about making it at all pretty, we'll redo the code and ui lots of times, but do it to just get a feel for the app.
reply | edit
jesse - December 24, 2007 7:57 AM
christmass a day early!
Typing with my iPod touch now. Just noticed that the calendar on the touch has a list view that seems much like what we have been talking about hear. So the idea must have some value!
reply | edit
Bleicke - December 25, 2007 3:27 PM
http://the-gadgeteer.com/assets/apple-ipod-touc...
You mean something like this?
Also merry christmas to you! And everyone else who might be reading this ;) Hope you have a nice holiday.
reply | edit
Chris - December 20, 2007 8:13 AM
A candidate for the name: CalPaper. Parallel with TaskPaper -- same concept, no? -- and not used.
Cheers, Chris
reply | edit
Chris - December 20, 2007 8:15 AM
Or DatePaper. Perhaps even more parallel. Also not used.
reply | edit
Bleicke - December 20, 2007 9:22 AM
Since we're not focused on the "paper" aspect anymore, I think "Paper" in the name might be misleading.
But: Today was my last day at university for this year, so I'll have a lot of spare time in the next weeks :-) I will finally be able to try what we came up with so far!
Bleicke
reply | edit
jesse - December 20, 2007 9:26 AM
No more school, no more books, no more teachers dirty looks! Congratulations!!!
I think I agree on the "paper' name for now. I think 'DatePaper' sounds good, but since this program that we are working on won't mean 'paper' in the same way that TaskPaper does it could be confusing. Also I think that using the same 'paper' name might lock us, and potential users into a bit of a box, thinking the app should follow TaskPaper's design more then it really should.
reply | edit
jesse - December 22, 2007 12:27 PM
You've probably already seen it, but check out http://www.anxietyapp.com/ It's interesting because it's using the calendar store api to provide a different view on todo item. You app will be similar in some ways, but instead will be providing a different view on event items.
reply | edit
Bleicke - December 25, 2007 3:29 PM
Hm, I don't see how the view is different. It seems more like a widget than an "application", at least from the looks of it. But the view on events is the same - a table view. I still think the idea makes not big enough of a difference to the user to pay for it.
reply | edit
Gregg Sewell - April 3, 2008 11:54 AM
I like the idea of a simplified iCal.
Here's a name to consider:
Save the Date
It implies all sorts of good things, but doesn't really address the speed issue. But that doesn't matter, if the principal blurb is killer copy. Try something like this:
Save the Date
A simpler, quicker calendar
Someone once said about website design that if a visitor from Mars couldn't figure out what your site is about in four seconds or less, then you've failed.
You can say all sorts of good things about your program once you've got people reading about it. But the name and the next four to six words (subtitle) should make them crave more knowledge about it.
If these ideas are good, then you may have them, no strings attached.
When you get a working version up and running, let me know. I'd be interested in testing it.
Peace,
Gregg
reply | edit
jesse - April 3, 2008 12:09 PM
Greg, thanks for your ideas. Unfortunately I'm not sure that this experiment will progress much farther then what you see here. I don't have time to work on a whole new project myself, and I don't think Bleicke is working on this anymore. But maybe someone else will come along and start the idea back up.
reply | edit
jesse - April 23, 2008 9:39 AM
Alas, it doesn't look like this project will move forward anytime soon. But some good news on this front, it looks like a new app was just released that implements some of this functionality. Check out Today 1.0
For me it still misses my goal a bit, since it's so focused on "Today"... iCal already shows a pretty good view of a single day. Where iCal has trouble is when you want to see (a bit lost of all events at once). So I'd like to see a similar interface, but showing of all my iCal dates, not just the ones that happen today.
reply | edit
Daniel Liu - July 23, 2008 12:23 PM
Jesse - has anyone attempted this project since? Found this post because I was looking for something similar. I got a minor in Computer Science, but I have never built a Mac app before. I'd be interested in this kind of "mentoring" to help me get jump started on this. I still see a lot of value in it.
reply | edit
jesse - July 24, 2008 6:32 AM
No, except for the above mentioned "Today" I don't know of any work being done on this. I'd be happy to see someone take it up.
reply | edit
Luke Pike - July 29, 2008 10:13 AM
Well, funny that this should come up. While working on the general logbook idea, I decided to take a little break from it and give the iCal idea a go, just for a change. And, it was surprisingly not difficult. The Calendar Store is so easy to use. Here's what I have so far.
You can use the arrows on the sides for going forwards and backwards a day or a week, depending on which view your in. Right now, editing the text does not edit the events, I'm getting ready to tackle that next, but I thought I would show what I have so far. I'm not sure, but maybe the logbook will have to be put on hold for now. The iCal project just came together so beautifully, and it looks like it would be more useful to your users.
reply | edit
jesse - July 29, 2008 12:12 PM
Luke, that looks great! Would you mind sending me the binary so that I can play around with it for a bit?
reply | edit
Luke Pike - July 29, 2008 1:32 PM
Thanks! I'll send it to you now.
reply | edit
Topic's comments