So, after all of 10 minutes of thought to naming, my girlfriend Melissa and I came up with the name Piki for the app, as a shortened form of Picture To Wiki. I’m planning on using my own preferred development process for this project, which is broken down into the following steps:
Definiton phase
Figure out basic goals
This is what the last post was detailing, the basic usage of the app. At this stage it’s more of a conceptual use case than a formal use case. Essentially, enough needs to be decided here to allow filtering of ‘better’ and ‘worse’ in the exploration phase that follows.
Exploration phase
Find and verify enabling technologies
This is where most technological architecture decisions are made, such as languages, libraries, communications channels. It consists of defining technical questions that we can use to decide which viable technology will be most beneficial, and answering those questions through a series of small demonstration apps. A primitive library can be developed in this phase to facilitate quick creation of the demonstration apps.
Workspace Creation phase
Create full-package process for chosen technologies
This is where you make a shell architecture that verifies the packaging system and supports all the app-external inputs and outputs. At the end of this stage, you should have a working installable. The reason for this stage to occur here is that often the packaging process itself presents unique technical constraints on the application, and before the final development, you should be aware of them. This is conceptually the final part of exploration and the first part of development.
Development phase
Implement the features you’ve explored
This is where the software architecture comes into play as you build out the application. You’ve already verified how to talk to everything, so the focus here is exclusively on how to make things talk together efficiently and intuitively, in a way that will support future goals.
Maintenance phase
Create new features, refactor, bug-fix
New features and certain refactorings can potentially follow the whole process again, but bug-fixes mostly stay at the outer fringes of the development phase.
I’d contend that this differs from both ‘Agile’ and ‘Big Up-Front Design’ approaches. Agile methodologies go straight to the workspace phase, or in worse cases, the development phase, and often suffers architecturally as a result. Big Up-Front Design typically tries to design before the necessary exploration.
This is the first of several posts concerning the research & development of a small app concept that I’ve decided to make. The need for this app arose out of a conversation with the development manager at my current place of work. The work this particular company is involved with is maintenance work for a monolithic VB6/VB.NET application (in-memory size of over 700 MB). With a high turnover rate, the current situation at that company is that no one has a full sense of the application, and everyone is essentially paralyzed by lack of information. I was suggesting that with a wiki, we could begin to build a knowledge-base that would support bringing people up-to-speed quickly.
My manager raised the very real issue of wiki markup and document interaction being a significant barrier to entry compared to putting documentation in Word documents. At this company, screenshots form a significant portion of the needed documentation for our app and the interaction with it. In a word document, or in an Outlook email, you can simply paste the screenshot right into the document you are working on. Of course, this is not possible with current wikis, because editing of wikis is done in plaintext. To add an image to an article, you might do something like this from the Fractal entry on wikipedia:
[[Image:Mandel zoom 00 mandelbrot set.jpg|300px|right|thumb|The [[Mandelbrot set]] is a famous example of a ”’fractal”’.]]
When you add this image link, you can upload an image from a form accessible by clicking the link. The problem with this is it takes several steps to put a screenshot in.
For Word:
- Browse in the document to where you want the image
- Get the screenshot (Alt+PrintScreen or just PrintScreen)
- Bring the document into focus (click on it from the start bar, or Alt+Tab)
- Paste the image
For the Wiki:
- Make the image stub on the wiki
- Get the screenshot
- Open a picture editor capable of saving images in web format (png, jpg, gif)
- Paste the image
- Save the image to a temporary location
- Click the image stub to access the upload form
- Click the upload button to bring up the filesystem browse
- Upload the image
In addition to taking longer, the wiki version requires you to do two namings of middle products: one on the wiki when you name the image stub, and one on the filesystem when you save the screenshot to a temporary location. The wiki naming is good, because it supports versioning and having multiple wiki pages point to the same image, but the local naming is entirely un-necessary.
It’s easy to see that this takes significantly longer. My goal with this small app is to make an app that sits in the system tray and allows ‘pasting’ to the wiki, so that putting an image in the wiki is as simple as the following workflow:
- Get the screenshot
- Click on the system tray icon for the app, bringing up a window
- Paste, which brings up the image, handles putting it into web format, resampling to web-reasonable sizes, and allows cropping
- Either:
- Paste New, creating a name for the image on the wiki
- Paste Into, selecting the name from the available names on the wiki
