What features would you like me to add?
The wiki is pretty much where I want it to be now. My todo list is basically made up of underlying changes to the parser to improve performance (particularly when running on Windows Mobile), and make the syntax a little more flexible (for example, currently links are not permitted in headings, because of the way that headings are parsed. I'd like to remove these and a few other such restrictions).
So these are a given - I will be doing these when I get round to it. But I have no other plans. I use the wiki every day, on both Windows and Windows Mobile and the interface and functionality has now reached the point where it suits my needs.
If the same is true for you, brilliant. Let me know if you ever come across a bug and I'll try and fix it, but otherwise the wiki is what we want.
However, if you want it to do more, now would be a good time to let me know. Is there any piece of functionality or change to the interface that would make your life easier, or save you time?
Let me know with a comment to this blog post what feature(s) you would like to see added.
posted by Dale Lane @ 9:19 PM
9 comments
9 Comments:
Nice app!
Things that I would like to add:
- picture support
- attachment support
- able to link to windows mobile contact/calendar event or task
Thx!
Hi
Thanks for the suggestions - here are my thoughts:
* Picture support
As in an IMG tag? Hmmm... could do. Not a bad idea - feel free to suggest syntax for how that could look, but I'll give it a go.
I've read that Windows Mobile 6 includes an API for receiving stylus drawing input. That'd be pretty nice, so if I ever get a WM6 device, I'd like to add support for drawing directly on to pages. That's more of a long-term idea though - can't see me buying a new PDA anytime soon! :-(
* Attachment support
The wiki already supports links beginning [file://blah] (or [[file://blah][This is my file]] for better naming), which I use to associate files with wiki pages.
What else would you like it to do?
* Link to Pocket Outlook
I'm less keen on this... it's a nice idea in theory, but could be a big pain to implement. (Plus it would fork the desktop and mobile versions more than I'd really like.)
That said, I'll take a look at it, and if it's not too onerous, I'll give it a try.
Very nice application. I have been looking for something like this for a while, and your bLADE Wiki is just great.
My number one suggestion is to make bLADE Wiki more stable. It sometimes crashes for me. (I am using version 1.12.3 on my Samsung i730 PDA running WM5.)
Another suggestion: Support for multiple directories for wiki files. This would make it easier to separate work data from private data. For example, I am contemplating using bLADE Wiki for work and sync the data directory with my work PC. However, I don't want my personal notes on my work PC. For example, [work/todo] would be a link to my work todo list, while [personal/todo] would be a link to my personal todo list -- the former would be in a directory called "work" and the latter in a directory called "personal". If no directory is given, then use the same directory as the current page.
It would also be nice to get rid of the extra newline characters in the edit TextBox.
Hi
Thanks very much for your comments.
> make bLADE Wiki more stable. It
> sometimes crashes for me.
It's difficult for me to do anything about this without more detail. It doesn't crash for me, so without any clue of where to start looking for a problem, I can't help. For example, if it throws an exception, then the stack trace would be useful. If it hangs, then a description of what you did up until the hang might give a clue.
For instance, last month someone sent me a snippet of their wiki page that caused the wiki to crash. Having an example that I could use to recreate the problem meant that I could fix it within an hour of getting the email reporting the bug. (see here)
> Another suggestion: Support for
> multiple directories for wiki
> files.
It does already do this - you can alter the location of your wiki by referring to different directories, and switch back and forth between them as needed.
The menu item is "Locate your wiki" on the desktop, and "Locate wiki" on the mobile.
> It would also be nice to get rid
> of the extra newline characters
> in the edit TextBox.
I've heard this before... it seems to be a problem with the character code that some mobiles have associated with their 'Enter' key. I've tried working around this before without much luck, but I'll take another look.
Kind regards
Dale
I am using an ipaq with a 240 by 240 screen. When I use your application, the bottom part of the page in edit/view mode cannot be seen because your program probably expects a 240 by 320 screen. Is this easily fixed?
@edward
There is nothing specific in the code about the size of the app - it was written to fill the size of the available screenspace.
I've tried it using an emulator with a square screen, and it seems to work okay, so I'm guessing the problem that you are having is something different.
If you can get a screenshot of what you are seeing, that might give me a clue.
@anonymous (1)
picture support is now added.
sorry for the delay ;-)
I've made these requests before, but I'll post them again (since you asked!!)
1) It'd be very nice to have a feature similar to the "back links" feature of NoteStudio. In my opinion, this is the primary reason NS became such a popular app.
2) I absolutely LOVE that the data is stored in .txt files. These are readily searchable by desktop search engines (Google Desktop and kin), which means that data stored in your wiki can be searched right along with everything else.
That being said, if the text files used a different extension (.wmw or similar) then maybe they could be associated with your application. Then, if double-clicking on a WMW file (or selecting it in a desktop search program) would automatically call up the correct page in the Wiki App... well that'd be incredibly fast and useful.
@chase
I've added the backlinks feature - in version 2.4.0. (sorry for the delay!)
I'm still thinking about how to approach the open-to-custom-page idea.
Many thanks
Dale
Post a Comment
<< Home