Indie Life

There are 13 entries in this Category.

Software ideas up for grabs

In case there are any programmers out there who have lots of time on their hands and don’t know what to program, here’s a few ideas that I’m surprised nobody has implemented, along with my suggestions on how you could fairly easily implement them.

Web Site Layouter

CSS supports absolute positioning of elements. However, most tools available for WYSIWYG site design restrict how you can position stuff. iWeb comes pretty close, but just doesn’t give you enough flexibility for themes, and Sandvox and RapidWeaver both only flow text and objects and don’t let you just position stuff by dragging.

So, my idea is pretty simple: Create a tool that takes HTML and renders it on the screen. Design this as “layers”, each of which has its own entry with absolute positions and the left/top values defaulting to 0. Use a WebView to correctly render each layer at 0,0 and draw it into an offscreen buffer (i.e. NSImage). Then draw all of these layers into your document window. When the user clicks, you loop over your layers in the reverse order as you’re drawing them, and check the pixel at the click position whether it’s opaque or transparent. If it’s opaque, that layer was just clicked.

Now, when the user clicks a layer, let them drag the layer, live. Save the position, and draw the buffered layer at that offset position. When the user requests to upload the page to a server, write that position to the CSS file.

WYSIWYG item positioning and correct HTML rendering the easy way.

Now, the hard part will be to actually edit each layer. You could do plugin-like objects that just output HTML to render that layer. E.g. a “table” plugin and a “styled text” plugin, and you could even use the new cool NSTextView features in Tiger to let users pretty nicely WYSIWYG-preview their images embedded in text. But really, positioning is key. If you’re a proficient CSS-maven, you might even manage to add other cool features, like Interface Builder’s “resize springs” etc., though that wouldn’t be as easy as what I outlined above.

Another neat feature would be a “block hierarchy”. What I mean by that is that users and plug-ins can define block types, a block simply being a chunk of HTML. Many of these blocks will do their thing to other blocks. E.g. the page would be a block that has one area for the navigation block, and another for the content block, and draws the design around those.

One block could be a “box block” that simply renders a box in the current theme and then puts another block with the actual contents inside it. Another block could be a table of image thumbnails in a folder, another a list of files in a folder, yet another block could be a box with a link to an RSS feed, that automatically adds the correct meta tags to get the blue ‘RSS’ button in Safari’s URL bar.

The neat part here would be that blocks generate their HTML based on the current theme. So I can have lots of boxes in my text for common elements like callouts, images with subtitles etc., and when I change the theme, they all change to match.

And as I mention above, there could be native-code plugins that are also blocks, doing all kinds of magic.

Simple Database

Basically, the code for this has already been written. You just link to libSQLite, stuff the database file and a layout description file into a document package and slap a GUI on top. If you look at AppleWorks’ database module, that’s the kinda structure I’m aiming for. You create fields, you can put them on one or more layouts, you can edit, view and print a layout, and search through the fields in the database and show the results using a layout of your choice.

Slapping a GUI on top would essentially mean you code a WYSIWYG UI editor that lets users place text fields, check-boxes, radio buttons, pop-up menus, list boxes, fields with stepper controls (“little arrows”) and any other UI element you can think of on the screen. Each of these would be hooked up to one particular database field in a table. Keep in mind that users may want different views on the same fields, though.

So while they want to be able to just compose a window full of controls, they may want to print as a table/list one day, and as a stick-on label the other day. So, you’ll want to have some simpler and fancier styles as well as standard controls, and you’ll want a table view and list view (i.e. several records shown on the screen, with their controls, not just one).

Also, the database may contain more information than you’d want to print on a label for shipping, so allow for not having all fields in a layout. You’ll also want to offer some drawing tools in case someone wants to draw separator lines, boxes, or put a logo on his disk labels, and don’t forget a text tool for e.g. labelling (groups of) fields with text that doesn’t come from the database. Of course, we also want to store text and styled text in the database.

You’ll probably want to have one object that owns all the controls for a particular field in a particular layout. That way, a user can change the display style of a field. E.g. you could have a number field which can be shown as a slider, an edit field (with or without stepper control), or as a radio button group, or as a list field, or… So, you’ll want to be able to show the same field with a new style just by changing a property, but without losing the actual data.

Main purpose of this: Just general keeping and searching data on-disk (user accounts, info on books I lent out, database of addresses to send my newspaper to…), but also printing of lists and labels.

And once you have that finished, there’s always advanced features: File references (i.e. store an AliasRecord as a BLOb) would be kinda nice, as well as references to records in other databases. If you give each entry a unique ID, you could probably just store this unique ID, and store the database file for that ID along with the field definitions and layouts “globally” in your document (i.e., I don’t think you’d need to be able to have a different database for each record).

In addition, you could add a little expression parser that lets you create field values calculated from other fields’ values (e.g. calculate someone’s age based on their birth year, or concatenate a “product prefix” and “product version” field to generate a product code, or whatever…).

You can also go wild with regard to search, import/export, trigger AppleScripts when a particular field is changed, put a plainly readable XML version of a database into your package to make it easier to spotlight and to allow third-party apps to read your databases without having to restrict yourself when changing the database format… there’s a lot of cool features in there, but the basics are pretty trivial to implement and only require some time and polish.

Audiobook/Theatre Lines/Podcast Recorder

This last one is probably niche, so I’m not too surprised it hasn’t been done in this form. Still, I think it crosses enough markets that it would be possible to make a viable product out of this:

Basically, it would be an audio-recording app. Feature set not unlike Audacity (or an updated version of Farallon’s SoundEdit), but with one distinction: A workflow that allows me to set chapter markers by pushing a button during recording, and perform other simple but common editing tasks while the recording is still going. What for? Well, several uses:

  • In Podcasts, add chapter markers or put bookmarks in spots where e.g. the Skype recording has broken up.
  • In audiobooks, mark the start of a new sentence. If I mis-pronounce, I simply click a button, and everything up to the last chapter marker is marked for deletion. I simply read the sentence again (and again, and again) until I get it right.

So, the editing that happens would only consist of marking up the recording with metadata, and updating the display (which would probably be some sort of wave-form display with selection). There would be no need for the delays often caused by stopping and restarting the recording, as it would just keep going. Only once the recording has finished would the actual sentences be deleted. Heck, it wouldn’t even have to delete them right away, it could keep the various versions of the same chapter and let me choose between alternatives.

While Garage Band has a vaguely similar feature, it is aimed at musicians: You can mark an area that is a certain time long, start recording, and start playing your instrument. Once recording hits the end of the time range, it will then restart recording from the beginning and let you play a new version of this particular range. But it is always of fixed length. When I’m reading a novel as an audiobook, there is no predefined length for a sentence. I might try reading it fast, realize that doesn’t work, then want to re-read it more slowly.

So, why do I mention theatre lines here? Well, when I learn my lines for a play, what I usually do is I record everything into an MP3 and then listen to that on the morning commute. By hearing my lines every day, having them repeated to me over and over again, I can much more quickly memorize everything, and I can learn the lines on occasions where I can’t have the textbook in front of me. The general workflow is the same as an audiobook, though: Read text out loud, and delete any sentence I screwed up and record it again until it’s OK.

Any takers?

If anyone happens to implement one of these ideas or knows of applications that already do this, let me know. (And no, FileMaker or MySQL with phpMyAdmin don’t count – I want something small and simple, like Tables, but for databases/web sites).

Update: Added mention of blocks to web app.

How to send smart Bug Reports

I just came across three nice articles on bug reports, how they are filed by customers, and what all customers (including programmers who are customers of others) can do to increase the likelihood of their bug being addressed. Luckily, I generally get good bug reports, and when they aren’t, it’s usually my fault (e.g. I currently get crash reports for the Moose, but I have no way to let users tell me what they were doing at the time, or to specify their e-mail address so I can ask them for more info). Anyway, on to the articles:

Most of these articles also have great comments. The Executive summary of them all would probably be: Remember to state your problem that you’re trying to solve, not just how you’d change the program to solve it. The programmer might just be able to surprise you and solve your problem with a much better solution.

Also, make sure your bug report covers the following three points in detail:

  1. What you did. In the form of actual menu item choices and what button was clicked, e.g. “Double-clicked my image file’s icon in Finder”, not as a short summary like “I opened a file”. However, do also include an additional higher-level summary of what you were trying to do, like “I created a PDF image and wanted to put it on the web. For this I wanted to run it through Frobnitz to defrobnicate the file prior to uploading it.”
  2. What happened. In detail. Not “it didn’t work” or “it disappeared”, but rather “the application Frobnitz’s windows disappeared from the dock and a window showed up ‘the application Frobnitz unexpectedly crashed…'”. And always try to quote error messages verbatim. Sometimes a program has several error messages that differ in one word only, and if the programmer knows the exact text, they can find the spot in their code where it actually crashed.
  3. What you expected to happen instead.


Update: Added a link to Daniel Jalkut’s entry on the topic.

Automatic Software Updates – Making User and Developer Happy

Executive Summary: Users want to achieve certain goals through using your software or web hosting service. During important projects, users often don’t want anything to interfere with their achieving these goals. Updates always have a chance of going wrong. So, make sure they are informed of any updates you perform, don’t update invisibly in the background, and leave them the choice when to update in case they’re in an important project right now. If you show respect to your users and what they deem important this way, not only will your app serve them better, they will also appreciate your work more, and consequentially be more likely to stay your customers.

I just came across a new article by Aaron Ballman asking why some users don’t update their apps, even when it’s a free update. Aaron argues that he spends a lot of time on his updates and fixes lots of bugs, and thus is kind of surprised why someone wouldn’t want all that free goodness.

A visitor named Steve answered that the reason is probably that they fear it will introduce new bugs, and could destabilize their system at an inconvenient time. Another visitor, Damon, mentions he took the route of a benevolent dictator and just made his app auto-update to make sure his users don’t have to live with bugs.

Damon’s method would make me drop that program quicker than a hot coal, exactly for the reason Steve mentioned: Never touch a working system. I may be using that app to work on a diploma thesis or another important project, and if the update introduces a show-stopper bug and thus makes me miss my deadline, I’ll get very annoyed.

Applications are tools to get work done. This work may pay, or it may better the world, or do whatever else I think is worth achieving. Usually that involves manipulating some sort of data that I spent a lot of time to collect or create. Since this is my data and my time, I also expect it to be my choice when to risk that data. By giving me the choice when or whether to update, application programmers show they respect my needs and priorities (even though most of them probably don’t share them).

From that results an obvious way to encourage me to update: Make it possible to install the new version independent from the old one and use both as needed, without either affecting the other. If I know that I can just launch the old version to get my production system back, or if I get an archive-and-restore feature, I’ll have much less qualms about updating. (I think there are some FTP clients out there who advertise that with every update.)

Another part of this is making it more convenient and less interrupting to install an update. If I only get a web site link, I’ll often wait a week or two, until I have some idle time on my hands, at least if I don’t see an immediate benefit to me in the announced changes (“miscellaneous stability improvements” are too vague, unless it keeps crashing on me right now). I may not update right away, but I’ll usually do it in a while.

Updates that at least download the file for me without having to click through a web page will be applied a little quicker, because it saves me time. I’ll have the file on my hard disk to copy over as soon as I feel like it.

Extrapolating that, self-updating apps should be a hit. But they only are if they respect my data and my needs: Can I easily revert to the old version, including all previous configuration files (Preferences, templates, patches)? Do all these features work reliably?

For example, sometimes Photoshop Elements takes hours for me to launch because it downloads a new version of the same three Adobe Online Something files, and even downright freezes during that. It costs me time and forces me to force-quit and restart PSE, often several times in a row (which sounds trivial, until I need to do that important change to a graphic in the next 5 minutes or it won’t make it into print). Even worse, it doesn’t provide me any visible benefit. I have no idea what these files do, and they certainly haven’t fixed any bugs for me yet.

Seen from this angle, an incomprehensible action on the users’ part becomes a very smart one when seen in a larger context. Show your users that you respect them: let them choose the time of their update. And since your users’ mind is obviously on a topic that is more important to them than your update, remember that they may have forgotten your update by the time they’re finished with that more important thing. So, offering a third alternative to Install and Don’t Install, like Ask Me Again Next Week may just get you those missing ten updates.

Oh, and by the way, this also applies to web hosters: While it is incredibly nice to your clients when you install the newest updates and security fixes on their server for them, it’s a good idea to give them some advance warning. Often, such small fixes have unexpected side effects. If I’m a web designer and I just sent out a few job applications containing a link to my web site, a PHP error caused or exposed by such an update – usually not a show-stopper – may decide between me getting hired or ending up unemployed under a bridge. If I, the client, know there will be a change, I may be able to set aside some time to examine my site for deficiencies once the switch has happened, and thus avoid most of the trouble.

In addition, keeping your users informed about what good deeds you’re doing increases their awareness of and appreciation for the work you’re doing. Customers that know you spend every odd week installing the newest security fix, scanning the file system for unsafe permissions or that you just replaced one of the hard disks on the RAID that was about to fail, will not see you just as some guy who buys a computer once, hooks it up to the net and from then on only cashes in checks and drinks lemonade on the balcony. They will know they’re actually getting good craftsmanship for their money. And when they know that, they’ll be much less likely to move off to another hoster that offers the same server features for a buck less.

Update: John Gruber just posted an article on a practical example of changing the user’s system without them knowing. He doesn’t quite express the value your user’s data point of view, but I think he basically means the same thing.