Before I get to the main topic, just a short update on my novel :). I wrote a few more chapters and I have some new ideas, but I feel that I need some break. When I first started writing back in 2011, I was so involved that I could write all night, but now I have to get up earlier and generally I have too many things to do to be able to fully concentrate on this. So it's becoming a somewhat tedious process, quite like programming that I was trying to escape from. However, the result is still quite good and I'm certainly not going to leave it off.
Anyway, I can't ignore the fact that the idea of WebIssues 1.1 is growing in me. I've already had some items on the roadmap, but there's so many of them that I will have to split them into two releases. I'm probably going to postpone all improvements related to users, groups and permissions until version 1.2. The main improvement in version 1.1 will be issue descriptions. It's something that's clearly missing compared to other bug tracking systems. Of course, the first comment can act as a description, so the change is a bit cosmetic, but the ability to provide the description directly when creating an issue will certainly be an improvement. During the upgrade from version 1.0, the first comment will be automatically converted to a description.
Also projects will now have a description. There will be a project summary page, which in the future may contain other useful information, such as statistics, recent issues, etc.
The last (but not least) improvement in this area will be the ability to use simple formatting in both comments and descriptions. And that's an interesting problem, because there are lots of different markup languages that can be used to add formatting to a piece of text. Each existing standard has it's advantages and disadvantages:
- Powerful and good for CMS, blogs, etc., but it's difficult to use by non-geeks. And it's even more difficult to display it correctly. A naive implementation opens the possibility for XSS attacks. Simple tools like kses still won't ensure that the markup is valid (e.g. check for unbalanced tags). More advanced tools like htmlpurifier are simply monstrous.
- Textile / Markdown
- They are quite different, but based on a similar idea: make the source text look as natural as possible. I prefer the latter, although they both seem to make more sense for writing longer articles (especially technical) than simple descriptions and comments.
- Wiki markup
- The main problem is that there is simply no such thing as a standard Wiki syntax. Although there are many similarities, each implementation has its own flavor. Also note that adding true Wiki support to WebIssues (i.e. being able to create cross-links based on titles, not just issue IDs) would be an entirely different story.
- Simple and widely used (also with many different flavors). On the other hand, square brackets don't seem more intuitive than angle brackets used in HTML.
This is a broader topic and I will write more about it in a separate post. So far I'm leaning towards a subset of Wiki syntax with some modifications, but I have to think more about it. And don't even get me started on the so called "WYSIWYG" editors. They are bloated and/or buggy and not 100% portable. I think I'm going to create something based on markItUp which is small, simple and easy to customize.
Yet another area of functionality that sooner or later must be (and will be) added to WebIssues is support for inbound emails. Some thoughts have been circling around and a few different persons have offered to help me implement this. If something gets done then I will include it in one of the next releases, but for now I can't promise anything.