Hog Bay Software (Incubator)'s topics

SwiftCal

Luke Pike — Wed, 13 Aug 2008 11:52:00 -0500

As you may know from the original thread, I am now actively working on the simplified iCal project. Jesse has come up with a working name for the app, SwiftCal. There are a few issues that are undecided, and that I would like your feedback on. But first, some screenshots of the current version:

The top bar contains a back/forward history browser, and next to that is a path control which shows you the current date being displayed. The content is basically a web page that is styled with a CSS sheet. Eventually users will be able to add new CSS sheets to make their own style. All the headers for the dates are links which will filter out all other dates when clicked.

Here are a few things that have not been decided yet that I would like your opinion on.

There currently is no way to set the date displayed manually. The app starts out displaying the current year, 2008, and from there you can click to other months and days. I think there needs to be a way to set the date by entering a year, month, or day into a text field, but I'm not sure if that's the best way.
Right now, search filters events in the current date range, such as 2008, August, or Thursday the 14th. I'm not sure how search will end up working, if there needs to be a search all function, or if its all right just to go to a date and search.
There will be a way to enter in new events with a quick entry HUD window. I am thinking of using a simple parsing structure as a way to enter in events. Something like "Lunch meeting @with Someone @date August 18 @location Some Restaurant". There would be auto complete for the keywords prefaced with @ so typing it in would not take long. There are many ways of doing this, so one method will have to be chosen.

Those are the issues I could think of, but if you have any more thoughts on things I didn't mention, please post your opinions on those as well. Any feedback is greatly appreciated!

General Log Book

Luke Pike — Sat, 12 Jul 2008 19:17:40 -0500

I am really interested in the idea of "user-generated" apps. Right now, I really don't have the resources to host a store and sell an app. But I would love to develop an app for the real world, and I really like the style of your business. So, here's my go at an application idea that I would like to develop and sell on your store.

For users who want to log information without the overhead of a spreadsheet application, Logbook is an easy to use program that lets you log anything with as much information as you want. Unlike other logging programs that are specific to a practice, Logbook is a general log book for anything.

So the idea is that when you make a new document, you add as many headers as you want, then you just create new items and add the information to the fields. Here is an example. Suppose I'm a runner. I would like to keep track of all my runs, and how well I did on them. I just open Logbook, create headers for date, miles run, the time it took, and anything else I would like to log. Then every time I go for a run, I just add a new entry, and enter the date, the number of miles, and so on.

Now I suppose you could use a spreadsheet program for this, but spreadsheets are good for presenting data, not keeping track of it. Also, you can't really search a spreadsheet very well. In Logbook, you would have search similar to a finder search, so you can add rules to the search.

So what do you think?

Do taskpaper support multi-languages or how to

Daves — Mon, 18 Feb 2008 22:54:53 -0600

Software seem no bad, I want to know whether taskpaper support multi-languages or not. Thanks.

personal software preview from Illinois.

notepad with tagcloud and multiple tag selection

osta — Sat, 02 Feb 2008 14:40:04 -0600

TagCloud: -multiple tag selections via click by click.

once selected tags are excluded in selectable tags in tagClouds. -positive tag/negative tag searching.
((+)application) ((-)apple) ..etc -bookmarkable tag selections.
directly create a notes that tagged on already selected tags. -automatic tag suggestion from word count , when finishing a note
this looks same feel of tag cloud. -show various list type of tag cloud.
new~old, Item counts, Access Numbers, Alphabetical....etc.

NOTE: -outlines. -cross link. -checkbox. -strikethrough style view option for changed note contents. -filelink -indexing

!!no directory structure !!just tags only.

Step 3 Describe your idea

jesse — Mon, 10 Dec 2007 11:09:46 -0600

Before you start development you should have a clear idea of what you are trying to build and what you are not trying to build. Having this early will help in all aspects of you app from coding to happy customers in the end. So for each potential idea that I have I fill out this positioning form from one of the marketting books above:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (statement of key benefit–that is, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

Example:

"For IBM PC users who want the advantages of a Macintosh-style graphical user interface, Microsoft Windows 3.0 is an industry standard operating environment that provides the ease of use and consistency of a Mac on a PC-compatible platform. Unlike other attempts to implement this type of interface, Windows 3.0 is now supported by every major PC application software package"

I also find a google unique (or close to it) descriptive name for the application, along with a tagline that will furthure describe the app.

Refining this description is an ongoing process that will continue through the life of the product, but I think it's important to get something good on paper before you start coding. If you can't come up with a short clear description of your apps place in the universe it is likely that your idea need more work.

First test, Simplified iCal

jesse — Mon, 10 Dec 2007 11:43:15 -0600

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:

Image TaskPaper showing you in text format the next week or so of your iCal events.
You edit it in text form like TaskPaper (so much faster than stupid clicking)
It goes right into your iCal so you can use it with all the other apps building on that (should work with the Core data system, but I haven't gotten to that part of the book yet!)

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!

Step 2 Hog Bay Software incubator reading list

jesse — Mon, 10 Dec 2007 11:08:59 -0600

Creating successful indie software is about much more then just coding an app. If you want to create something successful (and useful) you will have a much better chance if you learn a few things about marketing and buiness. Here's the sources that have most influenced the way that I think about the non programming aspects of creating great software:

Paul Graham - The Power of the Marginal http://www.paulgraham.com/marginal.html

"Small things can be perfect; big ones always have something wrong with them."

Clue Train Manifesto http://www.cluetrain.com/

This is what first convinced me that marketting and buisness stuff in general wasn't neccessary bad and slimmy. It's also the inspiration for building user-powered softare.

Bunch of marketting books...

To my brain (and this means that I'm missing quite a bit I'm pretty sure) most marketting books boild down to "be different" and describe that difference as clearly as possible to the potential cusomer. This is a really important lesson and I think it's important to get it drilled into your head so I recommend reading as many marketting books as you can take. They are quick reads, but in the end I think they are well worth it, you'll be building better more useful applications as a result.

http://www.amazon.com/Purple-Cow-Seth-Godin/dp/...=pdbbssr_1?ie=UTF8&s=books&qid=1196356386&sr=1-1 http://www.amazon.com/22-Immutable-Laws-Marketi... http://www.amazon.com/Positioning-Battle-Your-M...=pdsimbimg1 http://www.amazon.com/Crossing-Chasm-Geoffrey-M...=pdsimbimg2

E-Myth-Revisited http://www.amazon.com/E-Myth-Revisited-Small-Bu...

This books taught me that while I hate most franchises the "franchise" idea of standardized processes and ways of doing things is very useful.

Style: Ten Lessons in Clarity and Grace http://www.amazon.com/Style-Ten-Lessons-Clarity...

The truth is, as most of you can probably tell from my writing, I've never made it much past the first few chapters of this book. But even that has helped me a lot with my writing and thinking. I think that it is very useful to clearly position and describe my products before I start major work on them.

Step 1 Welcome and what is this about?

jesse — Mon, 10 Dec 2007 11:08:11 -0600

At Hog Bay Software I've been working on a user-powered prococess for building software. The idea is that users are allowed to take full part in all aspects of the development process. The goal is for everyone involved to have fun bulding useful software. I've also been focusing on a particular style (small simple apps) of software and particular style (open and personal) of running my buisness.

For me this has been a fun combination that creates useful results. I want to see lots of apps built this way and I want to see the process continue to improve, but I'm only one person and my resources are limited. To make this grow I need more more developers invested in the idea, but I don't want to manage employees.

So instead I've created this forum and a proposal...

I want to host your application on the Hog Bay Software site if you build, market, and support it in the Hog Bay Software "style". This user forum is where we (me, you the developer, and any interested users) will discuss all aspects of your applications development and what needs to be done to make it successful and possibly sell it through my site.

Participating in this forum with your appliction idea doesn't create any sort of contract. You can sell the app yourself if you want, and I'm not promising that I will host your application. But hosting your app is certaily my goal, I think if we can create a "cluster" of simple user-powered software made by individuals it will helps us all be more succesful and build better software. If for some reason I don't want to host your app on my site the Hog Bay Software frameworks that you will build your app on are all open source, so you can sell it anywhere else that you like.

This idea is likely to fail a few times before it works, but in 5-10 years I hope to turn the Hog Bay Software site into a place with lots of small simple apps developed in an open and personal style.