- Apply usability techniques to language design in the same way that you would to GUI design. Use terms that domain experts understand. Where possible, avoid introducing concepts that are specific to applications in the domain, rather than to the domain itself.
- Develop the format together with software that reads and writes the format. Use evolutionary delivery to deliver early versions of both the format and the software, with frequent iterations to get both working well together. This particularly helps for meeting the twin goals of completeness and usability.
- Make sure that the format can exchange data in both directions with at least one market leader in your application area. Do this as early as possible in your development process. Do not expect the market leaders to do this for you.
- Market to other developers who would get a business benefit from using your format. This will be difficult until your format can exchange data with a market leader.
- Give format developers good support. Involve the development community in the design of the format. Be responsive to developers who are using early versions of your format and translation software.
- Avoid overhead. In a small market like music notation software, organizations like ISO and OASIS can be too costly in both time and money for even the largest industry players. Following the model of Adobe's PDF format - an open format under single company control - can be more effective in these situations.
In short, I think our instincts for what to do and how to do it have been right, or at least have been justified. I definitely see their point about standards organizations. Besides, they don't seem to want to talk to me anyways. :)
[ add comment ] ( 2 views ) | [ 0 trackbacks ] | permalink
If you are looking for ways to help (and I know that many of you are), here are some things that you could do:
- Get familiar with XML, XML Schema, and what I have done so far with KnitML. You certainly won't need the nitty-gritty details of XML Schema, but at least enough to understand which options are available.
- Take your favorite patterns and attempt to convert them to KnitML (as I have done with the sock pattern). If there are things that are missing from the XML Schema that you need, add a feature request on the SourceForge tracker. This will help us fill out the spec to emcompass all types of knitting. If it works and validates, I'll publish the pattern on the website.
- If you are a code geek, install a Java JRE and try to run the validator. Get familiar with the code base and make recommendations for improvement.
- If you are multi-lingual, translate the instructions.properties file into your favorite language using the conventions of that language. See if you can get the renderer to make the pattern look like what a normal pattern in that language would look like. If something doesn't work, submit a bug or feature request.
- Start building your own software that does something cool.
The possibilities really are endless. If there is anything else you'd like to do, including helping me refine the pattern renderer or expand the validator, please let me know.
Thanks for everyone's support!
[ 7 comments ] ( 141 views ) | [ 0 trackbacks ] | permalink
After poring over the KnitML Pattern Renderer code base for awhile, I decided that it is finally time to check the project in to SVN. Run com.knitml.renderer.driver.Driver and see what happens!
Right now, the driver program renders much of the pattern, with some quirks and omissions (and a stack trace to boot!). Also, I feel a bit guilty about this, but there are absolutely no unit tests for the pattern renderer. I know that they should be there (and I hope to get them there soon). It's just a bit more of a pain to run the XML-based tests, and I haven't really established the framework code necessary to do that just yet.
Here's the architecture in 500 words or less (and no pictures). The Pattern Renderer project uses the visitor pattern (just like the Validation project) to walk through the XML and send rendering events to the provided renderer. The file it uses (validated-pattern.xml in the com.knitml.renderer.driver package) The rendering implementation I am using, BasicTextRenderer (in the com.knitml.renderer.impl package), is largely driven from Java resource bundles, making it easy for messages to be locale-specific. Currently, all instructions are in the instruction.properties file in the base Java directory (next to the Spring applicationContext.xml file). If you don't like the way some of the messages are written, it's easy to change them to the verbiage you prefer. I'm not suggesting that end users will ultimately be opening text editors and changing property files, but you have to start somewhere! I currently have some indenting problems that need taking care of.
I had to alter the way the "turn the heel" instructions were organized. Instead of embedding an <instruction> tag inside of a row, it was much easier from a rendering perspective to provide the ability to render a "row" that may not actually start at the beginning of the row (i.e. has unworked stitches before the starting point on the needle). So <row at-beginning="false"> now indicates that the row (which still gets a new number) starts with unworked stitches on the right-hand needle. This is mostly a directive for the validator to prevent freak-out under these circumstances.
I've realized that it is relatively difficult to write algorithms for processes that most of us don't even give a second thought to. This time around, it was the idea that the instruction such as this one:
<row number="1">
<repeat to-end="true">
<knit/>
</repeat>
</row>
should be rendered like:
Row 1: Knit
rather than:
Row 1: k to end
I had to write a recursive algorithm that, through process of elimination, had to "deduce" that it could render a simple statement. Much easier said than done. I spent a few hours on the plane working out the algorithm, showed my wife, and she replied, "You just spent the last 2 hours doing only that??" So it goes.
There are some ugly things about this code, and I am fully aware of this. There needs to be some refactoring and documenting to bring the project up to snuff. However, I felt that it was important to get something out the door and working, because I think a lot of folks are waiting for something to work with before they get involved.
Additionally, I found out today that KnitML got linked to from BoingBoing. The blog had about 6000 hits yesterday (up from an average of 20 per day). So the word is spreading, which is really exciting! I will make another post soon as to some things that you can do to help out immediately with the KnitML effort.
[ 1 comment ] ( 29 views ) | [ 0 trackbacks ] | permalink
So the KnitML subversion repository is now being monitored by FishEye. Thanks so much to Atlassian for free software licensing for open source projects, and to Cenqua for free hosting. Check out the URL on the Links navbar to see what's been happening to the code base.
Right now, it's just me as committer. You can see all of the changes I have made and how the various KnitML artifacts are shaping up. I've been sinking most of my time in the Pattern Renderer, which I haven't checked in yet. It's almost at a good check-in point, and hope to do that by the end of the week (before the real holiday madness starts). Full internationalization support is being considered every step of the way, so if you are bilingual and want to help translate the instructions into a different language, please let me know!
One of the neat things about loose coupling is the ability to swap out different implementations of various interfaces. I know that there is a decent amount of Python experts out there, so if someone wants to write some Jython-compatible Python modules, we can swap them in and out of the Java core without even blinking an eye.
Thoughts? Please leave comments! I'd love to hear from you.
[ 3 comments ] ( 28 views ) | [ 0 trackbacks ] | permalink
No, I haven't fallen off the face of the earth. I have been working on KnitML quite a bit, though probably not as much as I would like to.
The biggest change has been with project structure and refactoring. There is now a KnitML Core project which houses functionality common to multiple projects. The KnitML Validation project concentrates on semantic validation (and light transformation which adds information requested by the initial XML file).
The newest project is the Pattern Renderer, based on Core and the basic parsing architecture already developed in Validation. I also have done a ton of repackaging after studying the project structure in depth with a slick little tool called JDepend. The most important changes eliminate cyclic package dependencies. Any software which aims to be modular needs to be free of such dependencies, so it was good to know what was going on.
I have also contacted the Oasis-Open group to see if they are interested in shepherding KnitML as a standard. More than likely they will simply not respond after having a good laugh. If that happens, I think it will be extremely unfortunate, as knitters worldwide are too often underestimated. I will keep my fingers crossed.
Anyways, almost all of the interesting action is happening in Subversion on SourceForge. Go and take a look!
[ 4 comments ] ( 88 views ) | [ 0 trackbacks ] | permalink
Archives
