It's a little late, but technically it's still xmas today, so I'm happy to give you Markdown todo lists in WikiPack!
You can read a little about them on the WikiPack home page, but basically they work much like this video made while they were still under development:
Todo lists are available on the Personal plan, which is still free until we get WikiPack hooked up to a cash register. (It’s on my list of new year’s resolutions…)
Have a safe, & productive new year
So I hope you find them useful, and enjoy making the most of Markdown todo lists to be more productive in 2013!
Several people had commented that it’s difficult to insert links to other wiki pages while creating/editing a page, because the sidebar pane containing the list of pages is obscured. I had been feeling the pain of this issue as well, and have finally implemented a solution:
It’s pretty straightforward, I hope, but if you have any questions or comments, please let me know!
Finally tracked down and fixed a couple of niggling JavaScript bugs:
Layout corruptions when toggling a page’s favourite status
When clicking the star icon on a page to mark it as a favourite, the layout would become corrupted requiring the page to be reloaded. This no longer happens, so favourite away! (if I may use a noun as a verb…)
Cause
Firing off concurrent AJAX requests that update various parts of the page (the Pages & Faves sidebar panes)
Solution
Perform the AJAX requests sequentially. This is a bit slower, but you probably won’t notice as one of the requests is updating part of the page that is hidden from view anyway.
Sidebar loosing the selected pane
When marking a page as a favourite or setting a page as the default homepage, the sidebar was mysteriously forgetting which pane was selected and resetting back to the table of contents.
This was a tricky one to track down, but it turns out that it was caused by a patch for a security vulnerability that required a CSRF authenticity token to be explicitly included for certain types of AJAX requests. I wasn’t going mad, the application framework was actually resetting the session…
~~~
Glad to have those fixed. Apparently, the Markdown editor doesn’t work at all in Chrome, so I’d like to get that fixed next if possible. Chrome makes up about 37% of WikiPack users, neck & neck with Safari. Of the remaining 25%, most are Firefox users, and I’m very pleased to find that only 2.28% of WikiPack users are on Internet Explorer :)
Previously, we aded the ability to mark pages as “favourites” - there’s a pane in the sidebar that provides quick access to your favourites, which you can use for quickly navigating between your most frequently used pages.
Today, we’re adding the ability to set one page in particular as your “homepage”. There’s a new home icon in the menu bar which will jump straight to it from anywhere in your wiki, and it will also be the first page that loads whenever you log in.
~~~
Setting it up
I found for some reason that when I tried using it on my own account, I had to first log out and then log back in again. Some kind of strange session persistence issue across deployments? If you click the home icon and it doesn’t set the page as your homepage, try logging out and back in again and it should work fine.
For some time, I've been working on a solution to the "email to myself" problem. It's just so much easier when using various apps & services to email things to yourself for processing later than capturing them into some kind of task management system, especially on iOS where copy & paste and switching between apps provides consideraby more friction than the ubiquitous "share by email" feature, but your inbox is not a good todo list for several different reasons.
It seems like I'm not alone. Agile Tortoise, makers of the awesome Markdown scratchpad Drafts, recently blogged about it too, saying that many of their users have requested an "email to myself" feature. They proposed setting up a Twitter account, and using it in conjunction with a service called IFTTT. I'd like to offer another solution which works well with pretty much anything that can send emails, including Drafts.
Email to Markdown
WikiPack pages exist as plaintext Markdown files in a Dropbox folder, and when you log into your wiki, they are rendered as formatted HTML and linked together using WikiWords. As of now, each page in your wiki also has its own email address that you can send content to, using its WikiWord and your wiki's subdomain to form the address. For example:
Inbox@yoursubdomain.wikipackit.com
HTML email conversion
Most apps that can send stuff via email, like Safari, Reeder, and Flipboard use some simple HTML to apply some formatting and insert link text. The HTML will be converted back to Markdown automatically before it is added to the page. It supports basic HTML tags, not tables.
Plaintext emails
Some apps just use plaintext emails, which is fine, because Markdown is plaintext, so no conversion is required.
Using it with Drafts and other apps
Adding content to your pages is now as simple as sending an email. Here's how to do it in a few different apps:
Email to Markdown with Drafts
Drafts is the perfect comanion to WikiPack for quickly capturing ideas, and then adding them to a wiki page in just a few taps because it can preview the Markdown for you before emailing it.
It has many sharing options (which you can configure now), including Email and Markdown: Email. The Markdown: Email action will actually convert it to HTML, but we just want to add the raw Markdown to our wiki, so use the Email action instead.
Compose and preview your Markdown in Drafts
Hit the share button, and select the Email action
Enter the email address of the page you want to send it to and hit send
Once you've entered it, iOS will remember and autocomplete it next time
Email to Markown with Safari
The most common cause of "email to myself" behaviour in Safari is to store a link to the current page for acting on later, or bookmarking it. Make a Links wiki page, then just email the webpage to it!
Mobile Safari
Open a page
Tap the share icon next to the address bar
Select Mail link to this page
Enter the destination page's email address and hit send
Desktop Safari
Open a page
Hit SHIFT+COMMAND+I
This will open your default email client, like Sparrow for example
Enter the destination page's email address and hit send
Email to Markdown with Reeder
Tap the sharing icon in the top right while viewing an article
Select Mail link
Enter the destination page's email address and hit send
You can try the Mail article action, and it does a reasonable job actually, but will need to update it a bit to strip out the <style> tags.
Email to Markdown with Flipboard
Flip to a Tweet or RSS article
Tap the share icon in the bottom right
Select Email link
Enter the destination page's email address and hit send
A world of possibilities
It's early days for this feature, and with your input I'm sure it will evolve a lot, but there are so many possibilities for what you can do with it already. Effectively, I've just given you an API of sorts for converting emails to Markdown that is synced automatically to Dropbox. That's pretty cool!
Just for fun:
Open one of your pages in Marked
Type up some quick Markdown in Drafts and email it to the page
Watch in awe as the rendered page updates automatically in Marked
Let me know what awesome ways you come up with for using WikiPack's new email to Markdown feature!
78% of WikiPack users who have authorised it with Dropbox are using the template wiki in the /WikiPack folder that is created during signup
20% of current WikiPack users never authorised it to access Dropbox
5% of WikiPack users who authorised it with Dropbox are using their Trunk Notes folder
~~~
WikiPack - Full Dropbox, or App Folder?
So my question to you, dear readers, is which Dropbox access mode would you prefer WikiPack to use?
It currently uses Full Dropbox mode to allow you to browse to a folder outside the sandbox containing Markdown files and import them into your wiki, but only 5% of us have taken advantage of that. The vast majority of WikiPack users have been content to create a template wiki in a /WikiPack folder, which might as well be sandboxed in that case.
Please let me know what you think by voting in the poll above, or getting in touch be email/Twitter:
The following is a more verbose post on Dropbox sync:
Why applications use cloud sync
The most obvious reason for using cloud sync services is to share data between applications & devices. For example, if you use the same app on your smartphone, tablet, and desktop devices, you want each instance of the app to share data & settings in order to provide a consistent user experience.
iCloud - sharing application data between devices
On iOS, iCloud serves this purpose well - iPhone/iPad/Mac apps can transparently share data via iCloud. This is fine if you only ever want to access the data with this particular application. It doesn’t help you if you want to work on it with other applications or command-line tools that don’t support iCould.
Dropbox - sharing any data between any device, application, or OS
Dropbox on the other hand is literally just a folder in your filesystem that you can do whatever you want with. Anything in your Dropbox folder gets transparently synced to the cloud, and it has become the de facto standard for sharing data between different applications across multiple operating systems.
The mobile client for Dropbox essentially exposes this filesystem to mobile applications as well, allowing you amazing flexibility in the range of tools you can use to work with your data.
Dropbox access modes
Dropbox offers two modes of API access to third-party applications:
Full - applications can read & write to the entire contents of your Dropbox
Sandboxed(“App folder” mode) - applications can only read & write to files within their own sandboxed folder
Take a look at your phone, and make a quick list of all the apps you have installed with Dropbox access. I have the following on either my iPhone or iPad:
Find any surprises? I was a little surprised to see that only Due App uses App folder mode, which it should as it only serves to share binary data between the iOS/Mac versions, but other apps like TextExpander that use it for the same purpose use Full Dropbox mode. Why do apps like Noteshelf that only export files to Dropbox need full access?
The de facto standard for iPhone app access is Full Dropbox, and most people don’t even know, or care, by why?
A matter of transparency & perceptions
When you authorise an iPhone app with Dropbox, you get a nice familiar login screen which looks like this:
Linking will allow this app to access and modify files in your Dropbox
Doesn’t sound so bad, does it. When you authorise a web application with Dropbox however, it presents you with the following:
This app will have access to your entire Dropbox.
Please make sure you trust this app before proceeding.
Wow, that sounds kinda scary, and is probably why 20% of my users have dropped out right there. What’s the difference in the kind of access to your data? Absolutely none
We inherently trust smartphone apps, because it feels like our data is safe & sound within our phone, but we instinctively distrust web services, probably because many of them have acted like dicks in the past with our data, so who can blame us?
It’s not easy to earn trust as a web application developer, so I’ve been completely open about WikiPack’s Dropbox sync, but having run the numbers, I should probably listen to my users and switch over to App Folder mode.
I was just about to go about my daily tasks, in this case processing an email, when I realised it might be of interest to anyone wondering how to integrate WikiPack into their productivity workflow.
As a general rule, no - as a strict rule, I don’t use my email inbox as a todo list, but rather process & then archive or delete them. If they can be acted on immediately, I do so, otherwise I’ll add an item to my todo list. The problem though is the disconnect between the contents of the email, and the todo item related to it.
One way I work around this, is by creating “throw-away” wiki pages for longer todo items. In this case, the email was related to school, so I edited my School page and added a wiki link like:
**[[School-2012-05-31|2012-05-31]]** - received an email with a list of schools to checkout
Hint: Use TextExpander to insert timestamps quickly
I then save my School page, and click the link to create a new page to receive the contents of the email. This way, when I hook it into my other productivity apps, it’s interlinked to my other School related pages. I love using wikis like that.
~~~
Integrating WikiPack with other apps
Having a dedicated wiki page to todo list items is really useful, but the possibilities are endless. Now that I have a wiki page, I can click through the links, find each school’s phone number, and add it to my page. If I need to find one of those numbers later, I can just load up my School page and look it up really quickly.
I’ve previously demonstrated how to hook WikiPack into AddressBook to use it as an ad-hoc CRM, but each page’s URL can be used in pretty much any app that will render it as a clickable link.
Markdown editor features
In the video I demonstrate a couple of handy features of WikiPack’s Markdown editor:
Turning a block of text into a bulleted list
Select a block, hit the list button
Turning text into links by pasting a URL
Select the text, paste in the URL
So now I have my wiki page, and made a video in the process. How productive! Wait, I’d better get back to work… where’s the phone?
I’m a bit of a keyboard jockey, where there’s a keyboard shortcut I’ll use that in preference to clicking UI elements with a mouse. Maybe it’s a bit old-school, but I find it to be faster and more efficient when writing in Markdown.
WikiPack provides GUI controls for most of it’s Markdown editor features, but also has keyboard shortcuts for things like bold & italic. Now, you can use the keyboard to insert links & images too!
Just paste a URL into the page, and WikiPack will take care of the rest for you. You can either position the cursor where you want the link/image to be inserted, or select some text and paste a URL over it. It knows whether the URL is to a webpage or an image, and creates the appropriate Markdown. This makes linking text to a URL really quick, and inserting images is now even more painless than before, I think it’s great.
~~~
Give it a try, and let me know what you think. Hopefully, it won’t raise the ire of too many people who just want to paste URLs without turning it into a link dang nab it!
It’s been an amazing journey working on WikiPack. I’m so grateful to everyone who’s signed up for an account, pushed the site to it’s limits, and helped develop it into a solid product. There’s still some polishing to be done, but the time to shed the “beta” banner and go live is drawing nearer.
What’s left to be done?
Going live will require some significant work around making a great marketing site, and implementing the billing mechanism, so during that time there will have to be a feature freeze. It shouldn’t be for long, but these kinds of things often take longer than expected, so ask yourself “If I could add/change/remove anything, what would it be?”, and have your say in the forums and the feature requests page.
Setting up a company
Why are these things so complicated? It’s not that bad really, the hardest thing is thinking of a company name. From my research, it seems that most of the software apps & services I use have a parent company name, and register their product names as trademarks.
Any ideas or suggestions? Tweet them to @wikipack.
Growth so far
The response so far has been phenomenal!
In the last week alone, 150 new wikis have been created
The growth rate from Jan-March was around 35%
The growth rate for April & May has been over 100%
In total, there are over 11,000 pages on WikiPack
WikiPack has performed over 13,000 Dropbox sync operations
99.23% of Dropbox sync operations have completed successfully
Humble beginnings, but I’m very pleased! The proof though will be whether this kind of growth can be sustained when it is no longer free…
Business model & pricing
The business model is simple, build an awesome product and ask people for money to use it. The challenge is deciding on the pricing.
I’m a realistic person, and I appreciate that most people who would even consider paying for a service like WikiPack would prefer the price to be as close to zero as possible. At the same time, the cost of the resources required to operate the service even at it’s current user base are beginning to stack up, so I need to find a comfortable pricing point that makes it appealing to you as a user, and viable for me as the operator. Maybe you’d like to help me decide?
My goals are humble: a few thousand people paying a few bucks a month would support future development of the platform. That would be awesome!
While the whole left brain/right brain thing might be debatable, there are definitely two schools of thought on how best to navigate and interact with information. I’ll term them “searchers”, and “sorters”.
Searchers
Searchers rely on metadata to retrieve the data that they’re looking for. They’re less concerned about where it’s located in their filesystem, or even what the file might be called, than having fast & powerful tools to find it for them by indexing and searching their metadata.
Sorters
Sorters love organising their files into carefully named hierarchical directory structures. They know exactly where to look when trying to find a file.
Visual models
It’s my guess is that searchers & sorters keep different visual models of their data in their minds. Searchers can visualise the data, and quickly produce keywords and search terms to locate it. Sorters can see a visual map of how their files and folders are laid out in their head.
Different modes of interaction
A search box is perfect for searchers, but leaves sorters wanting. Folders may be a sorters best friend, but go unused by searchers.
WikiPack left the sorters wanting, until now. It had a quick search box, but I get that a lot of people just want to see a list of their pages. And while it’s nice to be able to jump to a page by typing it’s name into the search box, it’s even nicer to have quick access to your most frequently used pages with a single click at any time.
Now there are complimentary tools to make navigating your wiki as quick, and simple as possible. In the sidebar where there used to be only a table of contents, there are now two additional panes: pages, and favourites.
Pages pane
The pages pane simply shows a list of every page in your wiki. You can scroll through and find the file you’re looking for, then click on it to go straight to that page. It indicates pages that have been marked as a favourite with a star,
Favourites pane
The favourites pane shows only the pages that have been marked as favourites. The sidebar remembers which pane you have open, so you can use it to really quickly jump between your favourite pages with only a click of the mouse.
First iteration
This is the first iteration of this functionality, and so far I’m really enjoying it. Now that the functionality is available, I’m finding myself using the mouse more, and I realise how some of you might have been sorely missing the ability to do so. It is a little rough around the edges in a few places, but the core functionality is tight and I wanted to get it out before the weekend for people to have a play with it. There will be further tweaks and refinements coming soon.
It’s now easy to change the Dropbox folder that WikiPack uses. Just go to your account settings page and click the “Change my Dropbox folder” button. You’ll end up back on the page where you can browse your Dropbox and choose a different folder to import the Markdown pages from.
~~~
Usual privacy disclaimer
In order to be able to use a Dropbox folder of your choice, applications integrating with Dropbox via their API must require full access to the entire contents of your Dropbox. This is a limitation of the API, but our privacy policy stands - while browsing your Dropbox to choose a new folder, WikiPack will read & display the filenames of your data, but will not read the contents of any files outside the wiki folder that you choose.
Just a quick update to add a keyboard shortcut for editing a page. When viewing a page in your wiki, hit Control/Command-E to edit it. Use the editor’s keyboard shortcuts for editing the page, then hit Control/Command-S to save it.
To jump to another page, hit the tab key, start typing its WikiWord, then hit enter/return. Rinse & repeat. Should be possible to do a lot more mouse free now.
More usable table of contents
The table of contents in the sidebar, which is generated automatically from the headings within your page, had an issue for really long pages where it would extend beneath the bottom of the page and some links were not accessible. It now scrolls, so you can access the TOC links at the very bottom.
Updated user guide
It’s not much of an update, but you can update the user guide to the latest version by going to your WikiPackUserGuide page and hitting the update button, or using the link in the account settings.
Firstly, I’d like to clarify the difference between “account sync”, and “page sync”. WikiPack turns Markdown files in a Dropbox folder into your own private wiki, which it keeps in sync with changes made by external applications.
Account sync
When viewing the list of all pages in your wiki, the Sync button will sync your entire wiki folder with Dropbox, checking for updated files, newly added files, and any files that have been renamed or deleted, and it applies those changes to your entire wiki.
It used to be s l o w … by nature of having to iterate through every page in your wiki and check for for updates, but Dropbox released a new API method to address that issue, which WikiPack has now implemented.
For this reason, I pretty much never used to use the account sync, mainly because it took too long, but now when I have a bunch of pages that I’ve updated on my Mac or with Trunk Notes on my iPhone/iPad, I can update my wiki quickly and easily.
Page sync
When you’re viewing a particular page, the Sync button just updates that page. My workflow often involves creating a blank page which I’ll just give a heading and save before opening it in an external editor, which may be TextMate + Marked, or an iOS app like Writing Kit. When I’m done, I’ll hit the Sync button again to pull the changes into my wiki.
First run
The first time you use the new account sync, it may take a while to complete, but after the first pass each subsequent sync will be much faster.
A note on security
As always, the privacy policy stands - the delta API will only give WikiPack the names of files outside your wiki folder, which it will ignore. It does not provide WikiPack with the contents of any files. WikiPack will only read or modify the contents of pages within your wiki.
In the beginning there was a boring, boiler-plate signup form with way too many fields. Some brave souls suffered through it, but complained about the complexity.
The next iteration was an attempt to simplify the process by reducing it down to just email & password fields, but there was still some confusion. It was trying to be too clever by generating a login user name automatically, when it could have just used the email address, and it wasn’t clear from the signup page what was happening now, and how much of it would be customisable later.
Sign up in seconds, and then what?
In a 37signals blog post titled “Sign up in seconds” … and then what?, Ryan pondered what would happen if you made it clear what happens next. I liked the idea, and decided to put it into practice and find out!
Clearer progress, customisable fields explained
The WikiPack signup process now clearly shows where you are in the signup process, and what’s going to happen next. It also shows the actual values of fields that are generated automatically from values entered into the form on the fly, and indicates when they can be customised later.
One issue in particular that I’m trying to address with this update is removing any ambiguity about the Dropbox integration by presenting as much information up-front as possible to save people from getting half way through the signup process and then bailing out if they decide that they don’t want/need Dropbox sync. The privacy policy is presented clearly, and the option to use the Lite plan without Dropbox sync is made readily available.
In a nutshell, we will always treat your data as your data and always respect your privacy.
Page caching
The page caching is a mechanism where your Markdown pages are stored in WikiPack’s database while various operations can happen simultaneously for improved responsiveness, such as viewing a newly edited page while the changes are being sent to Dropbox in the background. This does involve keeping a copy of your data on WikiPack, which we assure you is private and secure.
When not to use Dropbox sync
There has been a small handful of people who were reluctant to grant WikiPack access to their Dropbox folder because it requires full access in order to share your pages with other apps, but if you don’t want to share your pages with other apps, there is a Lite plan that does not use Dropbox sync.
What to store in WikiPack
Others have commented on using WikiPack for sensitive or personal information. Our recommendation as a general rule of thumb is not to use WikiPack to store any information that you wouldn’t be comfortable storing in other cloud-based services like Google Docs or Evernote. Not because it isn’t secure, or the privacy of your data isn’t ensured, but simply for peace of mind. Use the same sensibility & discretion with your personal data as you would for any web-based service.
Should you wish to cancel your WikiPack account, you can now do so easily. It will permanently delete all data associated with your account from the WikiPack database, but will not affect any of your Markdown files on Dropbox in any way.
Of course, I would hope that everyone who signs up for WikiPack loves it, but for anyone who for whatever reason decides that it’s not for you, you’re free to leave and take your data with you, because your data is always your data and WikiPack respects that.
Just added a user guide to WikiPack. It should be simple & intuitive enough to use without one, but for those who want a more in-depth understanding of various features it may be interesting.
~~~
New accounts
When setting up Dropbox you’ll be prompted to choose between using a template for your wiki, or choosing a folder to import existing Markdown pages from. If you select the template option, you’ll have the user guide automatically, but for those who choose to import a Dropbox folder you can insert the user guide into your wiki by going to the account settings page (click on your user name in the top right of the page).
Existing accounts
For accounts that were setup prior to this update, you can add the user guide to your wiki by going to the account settings page (click on your user name in the top right of the page).
Questions & comments
If there’s anything that’s not covered in the user guide, or you have any questions or comments, please drop us a line:
When viewing & comparing previous versions of a page, WikiPack used to only show changes that affected the rendered HTML which meant that you couldn’t easily see changes that didn’t affect the rendered HTML, such as the formatting of WikiWords within page links.
Now, you can both view and visually compare the changes between the raw Markdown of previous versions of your pages:
First of all, I’d like to apologise to any of you who experienced broken wiki links after the last update. I’m not going to hide behind the “open beta” banner, I made a mistake with the WikiWord generation algorithm and rolled out an update that affected people’s data without asking first, for which I apologise. This update fixes the problem, and provides an optional means of applying the fix to your Markdown pages.
What went wrong?
My updated algorithm stripped out some characters that it shouldn’t have, like the - character for example. So if you had a page named “Notes-2012-04-30.markdown”, it generated a WikiWord of “Notes20120430”. The updated wiki links may have worked in WikiPack, but if that page was also in your Trunk Notes wiki, which allows the - character, the previous update would have broken inbound links to that page.
The update applied the new WikiWord algorithm to your existing pages automatically in an attempt to maintain the wiki links between them and shouldn’t have caused any kind of disruption, but because of this error made on my part it actually broke those links for some people.
Repairing the damage
~~~
Your account settings page now has a “Regenerate wiki links” button which will apply the new WikiWord algorithm to your pages and hopefully reverse any damage made to your wiki links with the last update. This is completely optional, and should only be used if you noticed that some of your wiki links, especially for pages with non-word characters in the filename, stopped working after the last update. If you didn’t notice any problems then you probably don’t need to use the regenerate wiki links function.
The page History function should allow you to revise and rollback the changes made to your pages last week if needed. You'd have to navigate to the page in question, hit the History button in the sidebar, and then... well, comparing the changes wouldn't reveal anything because the it wouldn't have affected the rendered HTML, and there's currently no means to view the raw Markdown of previous versions... you could at least view the page as it was prior to the update last week and if the wiki links still work in that version you can revert it back easily with the link at the top of the page.
Again, I assure you that I always take the utmost care to preserve the privacy & integrity of your data at all times, so I regret that people’s data was affected by an error made on my part.
You’d be forgiven for not even noticing the difference with this update because it was quite subtle, but it was necessary to pave the way for some more updates that I have planned.
The dialogues for creating & renaming files used to be a bit confusing. It asked for a WikiWord, but allowed spaces and non word characters. Behind the scenes, it was actually using it to generate the filename automatically. This was unintuitive, so now it asks for the filename and generates the WikiWord automatically while displaying it on the fly.
If you’re not syncing your wiki folder with an app like Trunk Notes that uses a particular naming format, you can go ahead and enter spaces and other characters in your filenames, but if you’re using Trunk Notes you’d best stick to naming your files with a WikiWord otherwise they won’t be imported into Trunk Notes. The generated WikiWord will match your filename.
Phantom Dropbox syncing
WikiPack always maintains your wiki links, so as part of this update you may have noticed some of your pages syncing to Dropbox even though you hadn’t edited them. It was just updating your wiki links with the new WikiWords.
In the pipeline
Now that WikiWords are being handled in a sensible fashion, I’ll be working on a couple of other WikiWord related updates. Quite a few people have asked for a list of their pages in the sidebar, and I have one or two other things up my sleeve as well. Stay tuned.
I love the simple way that Markdown parses code blocks - just indent with 4 spaces (or 2 tabs). In a previous update, I added a button to WikiPack’s web Markdown editor for automating the process of working with code blocks, but it didn’t act on snippets of code within a regular line of text.
Delimiting code snippets
To insert a code snippet within a line of regular Markdown text, you just wrap it in “backticks” like so:
I strongly recommend against using any `<blink>` tags.
I wish SmartyPants used named entities like `—`
instead of decimal-encoded entites like `—`.
This is especially useful for displaying HTML tags and character entities within a Markdown document, as without delimiting them they will actually be parsed and rendered as HTML.
~~~
Checkout WikiPack’s awesome web Markdown editor with optional Dropbox sync at http://WikiPackIt.com.
WikiPack’s convenient Dropbox sync makes it a great online tool for those who love to use a variety of apps for working with their Markdown files, but for those who just want to edit Markdown online with it’s awesome GUI editor, it was a barrier to entry.
Yesterday, WikiPack added a “Lite” plan that provides all the awesome Markdown editing tools with wiki functionality, but without Dropbox sync meaning that you can be up and running in moments:
~~~
Free forever for early adopters
While WikiPack is in open beta, accounts are free and will remain free forever. You get to use an awesome online Markdown tool with Dropbox sync (optional), and I get great feedback and real-world usage stats back in return. So please go ahead and spread the word!
Following up from the last update that added smart bulleted & numbered lists, the WikiPack web based Markdown editor now also has smart quote & code blocks:
~~~
Smart, transparent technology
In keeping with the philosophy of making technology smart, but transparent, it does some things that you’d expect to happen instinctively, but may not be aware of while you’re using it. Especially the way it handles quote blocks.
The Markdown spec for code blocks ignores line breaks, but allows you to assert line breaks by adding a double space to the end of each line. If you’re typing into a text editor however and you hit enter, of course you expect it to be honoured as a line break, so WikiPack is smart enough to insert the double spaces for you automatically.
It also allows for nested quotes, but the implementation is a little quirky. If you simply attempt to nest a line by adding a “>” symbol, it will treat that symbol as part of the quote and render it as-is. To begin a new nested level, you need a blank quoted line above it, so when you hit the tab key in WikiPack it creates it for you.
Un-indenting is a little counter-intuitive though. Unfortunately, I couldn’t implement the ubiquitous SHIFT+TAB to un-indent the current line, but instead if you hit the Enter/Return key multiple lines it will un-indent the new line until it reaches the margin, at which point a subsequent press will remove the quote symbol and quit out of quote mode.
Full-featured web based GUI Markdown editor
With this update, WikiPack now has a full-featured web based GUI Markdown editor, with syntax highlighting. It occurred to me that it might be handy to add controls for adjusting the text size, but that requires inserting HTML tags into the Markup, which is extremely naughty. One thing that it doesn’t provide smart tools for yet is tables, but forget I even mentioned it… :)
Sometimes the best technology is the kind you’re not even aware of, but you become so used to it that you really notice something is missing when it’s not there.
Take lists for example. We’ve all used lists in a word processor before, and are familiar with how they work. You usually hit a toolbar icon to set the current line as a bulleted/numbered list, but the rest of the functionality occurs transparently, like the indentation and handling of the bullets.
So when you switch from a dedicated Markdown editor like Byword, to using WikiPack’s web editor, you instinctively expect it to behave in the same way, and now it does!
~~~
Markdown for the masses?
There seems to be somewhat of a plaintext resurgence of late, but there are some who feel that Markdown may confuse non-technical people. For WikiPack, it’s a key feature, but for some it may be a barrier to entry. My hope is that by making a web Markdown editor that abstracts a lot of the Markdown away from the writer with smart, transparent tools, that barrier may be removed, and WikiPack may yet see mass adoption.
Maybe WikiPack is useful to more than Markdown nerds and information hoarders like myself :)
I was quite chuffed when I added the automatic table of contents to WikiPack’s sidebar, and showed it off proudly to my wife who promptly observed that when jumping to a section of the page the causes it to scroll down far enough, the TOC scrolls up with it and vanishes…
So I started work on some JavaScript to implement the fairly ubiquitous “sticky sidebar” seem around the web these days. It took a while to come up with a solution that I liked, and here it is:
~~~
It’s not just cosmetic, it serves some important practical purposes:
the search box is always visible for quickly jumping between pages
the edit button is accessible when viewing the bottom of a long document
the sidebar controls remain visible when loading a page with an anchor in the URL
it makes the TOC really fun to use!
Couple of other tweaks
The search box has been refined since the last post, and the WikiWords are no longer split up at the suggestion of @frosty. (It was displaying iOS as “i O S”)
Thank you to everyone who takes the time to send in questions, comments, and feature requests. There has been quite a bit of demand for a few things that I’ll be working on next (in no particular order):
Having a list of all pages in the sidebar
Setting a default home page
Marking pages as favourites
One of my long-term features that I’m planning is a solution to the “emailing links to myself” problem, but that’s another story…
So I had just succeeded in hooking Time Machine up to a network drive attached to my Airport Extreme, and wanted to record the steps involved in my wiki by inserting screenshots I’d taken during the process. For a single image, I’ve shown previously how to use file sharing services like Cloud.ly, but ideally I’d like to be able to stick to using Dropbox.
Do Dropbox files have a public download URL?
No. I logged into my Dropbox dashboard and grabbed the download URL for one of my files, then tried logging out and accessing the same file, but Dropbox returns a 403 (forbidden) error. This is as we’d expect for our private files stored in our personal folders - we don’t want the whole world to be able to access them.
Getting the download URL of files in your Public folder
What follows is my first attempt at dropping a bunch of pics into my Public folder and inserting them in a WikiPack page.
~~~
This technique is great, because you can just drag stuff into your public folder and insert it straight into your wiki. Keep in mind though, that you probably shouldn’t put anything personal or sensitive in there.
The internet is ablaze with the news of the blogging site Posterous being acquired by Twiter, and what that means for their current users. So they decided to post an FAQ to address common concerns, to which it was commented upon on by @Documentally:
Startups need to factor in data portability from the start.
I couldn’t agree more!
Your data should be your data
WikiPack was designed from the ground up on the principal that your data should always be your data, and never locked into a proprietary data format or system. Some people might express valid concern at trusting a startup company with their important data for this very reason; the company could vanish, and take your data with it. OK, so they might provide archaic tools for exporting your data, but it will likely be of little use to you outside the system it was created with.
So if I’m hit by a bus, or WikiPack vanishes into the startup graveyard, you can rest assured that you’ll still have all of your Markdown pages safe and sound, right there in your Dropbox folder for Posterity. (see what I did there? :)
Just read an excellent post by Hilton Lipschitz about Markdown file extensions, where he makes the case for using .markdown, and I couldn’t agree more! WikiPack proudly uses a default Markdown file extension of .markdown, but gives you the freedom of choosing a different extension if you like.
I takes no more effort on our part to use longer, descriptive file extensions, and there are benefits such as being able to associate .markdown files with a different editor to other more generic text formats.
To me, it’s a no brainer, but I’ve seen similar issues manifest themselves in programming, where some developers lean towards shortened, abbreviated, often cryptic variable & method names. Why? Code editors these days have this great new thing called “automatic code completion”, so cutting down on typing is a non-issue as it’s mainly abstracted away from you. Similarly, once you create a file, you never need to type it’s file extension again, if ever.
WikiPack stats
Since introducing the ability to choose a default Markdown file extension to WikiPack, users have gone with the following:
Extension
%
.markdown
52.6
.md
31.6
.txt
15.8
Which Markdown file extension do you use?
Update 2012-05-23
The latest statistics from WikiPack users as of May 2012 shows a definite shift towards .markdown being the de facto standard:
Last one for the day, I promise! Borrowing (cough, stealing…) an idea from Brett Terpstra on connecting nvAlt & Address Book, I tried using WikiPack to do the same thing and whipped up a quick video in the process:
☙❦❧
Integrating with other apps
This technique can be used with any app that accepts text input, like TaskPaper which I use and love for managing todo lists. For example, I’m often debugging issues and have log file snippets and notes related to an issue I’m working on, but want to keep my actionable list in TaskPaper clean and free of clutter, so I’ll often add a link in TaskPaper as a note:
My important project:
http://beet.wikipackit.com/pages/ImportantProject
- improve test coverage
- fix issues
- deploy updates
TaskPaper will actually render the page’s URL as a clickable link, that opens it in a browser. Handy!
Following on from the last update which added a change history to your pages, this update polishes it off with the ability to visually compare between two versions of your Markdown pages:
Unlocking a hidden time machine
Did you know that when you use Dropbox to share your files between devices, it actually keeps a history of each change you make to your files? If you’re using the Mac/PC client, or an iOS app with Dropbox support, you’d never know, but locked away in Dropbox’s cloud is a history of your edits made from any of your devices & apps.
The only other way that I’m aware of to revert back to a previous version of a file is to log into the Dropbox website and do it manually. Unless you’re using a revision control system like SVN/Git, or Apple’s Time Machine, you may have experienced the frustration of having nuked one of your files. WikiPack just solved that problem.
For a Markdown editor with Dropbox sync, WikiPack is now an extremely powerful tool that lets you focus on writing your content without having to worry about what happens to it. Edit away, go crazy, because if you don’t like it or mess something up, you can easily compare it to an older version and revert it back as needed.
This is a bit of a game changer - WikiPack now keeps a history of changes made to your pages, and allows you to revert them back to a previous version!
It’s live now, and already provides access to changes made to your pages previously.
First web-based Markdown editor with Dropbox sync and change history?
For a wiki, page history is an expected feature, but for a web-based Markdown editor I believe this is a first. It is an extremely powerful feature that isn’t available as part of your standard suite of Markdown tools. The only other way to revert changes to your pages is to log into the Dropbox website and manually revert them back (or use a SCM system, or Apple’s Time Machine).
WikiPack is now quite possibly the first web application with Dropbox sync that provides a simple way of both editing your Markdown pages, and also viewing & reverting to a complete history of your changes. I’m really excited about this update!
Comparing changes
This is the first iteration of page histories, the next iteration that I’ll be working on is the ability to compare previous versions, so stay tuned.
Markdown has great support for images, and they come in handy for bringing WikiPack pages to life. I use them for a lot of things:
I keep a wishlist page with photos of iOS games I’d like to try one day, geek tools that look cool, and stationary items that I really like the idea of but will never use
Before buying new things, like a burr grinder or cold-press juicer that I’m considering at the moment, I research he best products out there on a page with links to reviews and photos of each item
I keep a page for my favourite apps containing tips & tricks, often accompanied by a screenshot
In this video I demonstrate two methods for adding images to your pages:
Hot-linking to externally hosted images (a bit naughty)
Using an image sharing service like Cloud.ly to upload an image from your computer
The method of embedding the image is the same in each case, using the following Markdown syntax:
A note on Trunk Notes images
Those of you who use WikiPack as a companion for Trunk Notes may be wondering about the possibility of supporting it’s images. Trunk Notes allows you to save images into a folder on Dropbox, and display them in your wiki using either it’s {{image}} function, or a standard Markdown image like .
As the files are stored locally on your iOS device, it doesn’t use any bandwidth to view images within Trunk Notes, but I haven’t implemented support for Trunk Notes images in WikiPack yet.
What I’m thinking about is looking into whether it might be possible to use hot-linking to display the images directly from Dropbox, because it won’t be practical to keep a local cache of a large no. of users images. At least not for the time being. If it turns out that there’s no other way to implement support for Trunk Notes images, it might have to become a premium feature or something. Not making any promises at this point though.
The secret sauce of WikiPack, so to speak, is the way it organises your information by linking it together. It does this by starting with a foundation of Markdown pages, and augmenting them with WikiWords that give your pages context, and form relationships between them.
What are WikiWords?
Say you have a page called "My sensible page of serious things". To represent that as a WikiWord, we remove the spaces, and capitalise each word to give:
MySensiblePageOfSeriousThings
So to add that page to your wiki, you’d create a page called "MySensiblePageOfSeriousThings", and it would automatically have your chosen Markdown file extension added to it. (You can choose which extension to use when setting up your account)
Linking pages together
The power of WikiPack is the way it allows you to freely link your pages together using wiki links. Currently, wiki links come in two flavours, standard and custom.
Standard wiki links
To link one page to another, simply wrap the target page’s WikiWord in double square brackets. For example:
[[MySensiblePageOfSeriousThings]]
Standard wiki links are rendered on the page as the WikiWord, in this case as “MySensiblePageOfSeriousThings”, but most times you’ll probably want to customise the link text.
Custom link text
To customise the link text that is shown on the page, use a “pipe” character | as so:
In this case, the link will appear on the page as “my sensible serious page”, or whatever you enter after the pipe.
Inter-page links
WikiPack builds a database of links between your pages, so that as you navigate your wiki you can use the convenient links at the bottom of each page to jump to other pages that link to it. As your wiki grows and you organise your pages in different ways by renaming them, it automatically updates the inter-page links, but will also automagically update the links within the referring pages.
So the context & relationships you create between your pages is always maintained, making it a powerful personal information organiser.
A note on naming conventions and Windows incompatible characters
If you’ve used an awesome iPhone app called Trunk Notes, or indeed many other wiki-like tools, you may have Markdown files using a naming convention like “Special:Header.markdown”, and may have even adopted it for your own purposes. I started using names like “Todo:Home.markdown”, “Todo:Word.markdown” etc. This helps give files context, and in WikiPack makes them easy to find using the quick search box, but unfortunately it causes problems with Dropbox sync.
It turns out that the Windows file system has several characters that cannot be used in filenames, including the colon. There’s a full list on this Dropbox support page:
< (less than)
> (greater than)
: (colon)
” (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
(asterisk)
The Dropbox API is inconsistent in that it allows apps to upload files with colons in the filename, but will not allow them to be renamed. Currently WikiPack will break if you attempt to rename a file and leave a colon in the filename, but I’m working on it.
Several people had commented on the overly clunky and complex signup process, so I made an effort to streamline and simplify it.
Where the initial signup form had a page of fields to fill in, it now just asks for an email address and password, and then walks you though the rest of the setup process:
After your account is setup, you can optionally customise some of your wiki’s settings:
Your wiki subdomain
A personalised name for your wiki
Your login user name
Your login password
Dropbox authorisation
I also polished up the Dropbox authorisation a bit. Some people were put off by WikiPack asking for “full Dropbox” access instead of “app folder” (sandbox) mode, but it turns out that when you’re using other apps that allow you to browse your Dropbox folder, they’re using full Dropbox access too.
Here’s a list of the apps I’ve granted access to my Dropbox folder, all using Full Dropbox mode:
You can check which apps have full access to your Dropbox contents here
Once you’ve either selected a folder containing existing Markdown files and imported them, or used the template option to create a new folder, WikiPack will only access files within that folder.
A keen observer noticed on the new WikiPack homepage that amongst the example usages were tracking fitness records and financial details like tax calculations etc. They also noticed that WikiPack does not (as of Feb 2012) currently use SSL encryption, so if you edit a page containing sensitive medical or financial data, it will currently be transmitted from your browser to the WikiPack servers in the clear.
Security vulnerability
What does that mean? Should someone with malicious intentions, and the appropriate technical expertise, wish to access your personal data, they could theoretically intercept it enroute.
SSL encryption
While WikiPack is in open beta, I have not yet purchased or deployed an SSL certificate, but will do so before going live. This will encrypt your data as it is transmitted between your browser and the WikiPack servers.
So, what’s stored on our servers?
You may have read recently of the debacle ensuing from the discovery that Path were uploading their user’s Address Book contents to their servers without their consent. They apologised and claim to have deleted the data, but some still feel it was disingenuous.
So I’d like to be forthright in explaining exactly what get’s stored on WikiPack servers:
Your email address (used to activate your account)
I did take the liberty of adding some early adopters to the mailing list with clear instructions on how to opt-out, which so far only two people have followed, otherwise you will not receive unsolicited email from WikiPack
Your user name
No passwords are recorded in plaintext
They are encrypted and cannot be recovered if forgotten
No Dropbox user details are stored on WikiPack
When you authorised your account with WikiPack, Dropbox provided a unique session ID which is recorded in the database
This session ID is only used by WikiPack to access the contents of the folder you selected when setting up your account
Page data:
The system keeps a local cache, in the database, of the complete contents of each page in your wiki
This database is protected by a secure Linux server
When you view a page on WikiPack, it is loaded instantly from the database, rather than fetching it remotely from Dropbox. This makes it fast, and responsive.
When you edit a page on WikiPack, it updates the database, and a background process picks it up later (a second or two) and uploads it securely in the background to Dropbox. Again, this ensures a fast, pleasant user experience.
WikiPack scans your pages for wiki links, and builds a tree in the database of how they are linked together. It uses this tree for presenting navigation links in the user interface only.
To summarise, WikiPack keeps a copy of your wiki pages in a secure database which acts as a local cache for read & write operations to your Dropbox files. This makes the system fast, and responsive. Attempting to load the data remotely from Dropbox each time you view a page would be slow, and impractical.
Your page data within the database is unencrypted, which means that if the database was compromised, your data would be accessible. I do not believe that will ever happen, but a relationship of trust should be built on facts, and that’s the reality of the situation.
A matter of trust
So my advise to you when considering whether to trust your data to WikiPack or not, is do not put any sensitive information in your wiki that you wouldn’t trust to other online services like Google Docs or Gmail.
As a general rule of thumb, if you’d trust your information to a Google Docs document, you’d probably be happy to put it on a WikiPack page.
I personally have my accounting info and my health & fitness records in my wiki, because I built it and I trust it completely. But I understand that you don’t know me, and might not trust me at all. That’s why it’s important that I give you as much information as I can so that you can at least make an informed decision.
In closing, I’ll be putting up a privacy policy page soon, and I believe that your data is as at least as safe on WikiPack as it is on most other cloud services, much safer in fact than some. Take that as you will.
Regards,
Mark Beattie
Developer & Founder of WikiPack
Very excited to announce that a new experimental feature has been added to WikiPack, a GUI Markdown editor.
It’s brand spanking new, and currently only has toolbar buttons for a few basic editing functions, but I’d like to get it into people’s hands to play with and find out what you think.
Couple of things I didn’t mention in the video:
Formatting text with bold, and italics:
You can hit the keyboard shortcut as you’re typing to insert the formatting characters and place the cursor in between them
You can then type the text that you wish to format
You don’t have to type the text first, select it, and then apply the formatting.
QuickCursor integration
The usual means of invoking QuickCursor doesn't capture the Markdown text; the editor window comes up empty
Before invoking QuickCursor, use your standard select-all keyboard shortcut (CMD/CTRL-A) and then invoke QuickCursor
iOS - a bit disappointed
I was really excited about getting the GUI editing features on iOS, because I personally use WikiPack on my iPad quite a bit, but unfortunately it doesn’t quite work as I was hoping.
Some of the toolbar buttons work, like the heading button, and the link/image buttons, but the formatting buttons are another story.
The problem is that the GUI editor is overriding the iOS text selection mechanism, so you can’t select words or position the cursor.
I’m disappointed about that, but will be working on finding a solution.
Another requested feature for WikiPack was the ability to rename & delete pages, and today an update has been rolled out that allows you to do just that:
Keep the feature requests coming by either taking a minute to fill in the feature requests form, emailing info at wikipackit dot com, or following @WikiPack.
Another cool feature is automatic generation of a table of contents for your documents. Especially handy for longer documents, it takes your headings and presents links in the sidebar that take you straight to that part of the document.
The headings actually have a permanent URL, so if you right-click on the sidebar links and copy the URL, you can use that to link to a particular part of your pages in other apps.
More updates on they way, but don’t forget to add your voice to the feature requests if you have a few minutes to click some checkboxes and help more WikiPack more awesome.
Since launching WikiPack in open beta, it’s been great getting feedback from the brave adventurers who have become early adopters. It’s been especially exciting because I’ve held back on building features until I’ve had demand for them from real users, but the features that I wanted to build myself have been the most requested, so I must be on the right track.
Even though I am scratching my own itch with WikiPack, I really want the features to be community driven, so towards that end I’ve made a simple feature request form that I’d love WikiPack users to fill in. If you haven’t already tried it out, head on over to http://wikipackit.com and signup now.
There’s also the user forum if you’d like to discuss any of these ideas, or add any of your own.
Having done some contracted writing myself, I can testify to the fact that organising the outline & structure can be a real pain, and a wiki would be a great tool to simplify the process:
"The home page is a plot synopsis with acts as headings–and links to a character page when they are mentioned. There are also links to past events, organizations of importance, fictional technologies, etc. Character pages have headings like “Early Life”, “Relationship with xyz”, and in standard wiki style, are interlinked. I also have a tab of snippets, with pages for loose notes, dialogue and ideas I’m not sure I’m going to use yet."
Awesome! I think the combination of Markdown + Dropbox would be a great tool for writers, because the text-based nature of the writing process affords a distraction-free writing environment, especially when using dedicated editors like Byword with a minimalist fullscreen mode.
Screenplay Markdown - SPMD
What’s even more exciting is the possibility of adding SPMD support to WikiPack. Now, I don’t want to get anyone’s hopes up just yet; implementing a new subset of Markdown isn’t on the cards for WikiPack at the moment, but Brett Terpstra has been able to add SPMD support to Marked already, so in theory you could start using WikiPack to organise your SPMD pages, and Marked to render them. I’m not a screenwriter, but if you are, I’d love to hear how you go with combining SPMD + Markded + WikiPack.
I love reading about exciting new uses for personal wikis!
Sometimes the coolest updates are the ones behind the scenes that would otherwise go unnoticed. You may have already seen how WikiPack can sync with Dropbox; it’s fast, and transparent. Well now it’s even better!
Room for improvement
To make the sync happen so seemlessly requires quite a bit of back-end infrastructure and engineering that I won’t bore you with, but while it was great, it was vulnerable to falling down when certain individuals decided to import a folder with several hundred Markdown pages in it. The system would become saturated, which would eventually result in it getting slow and unresponsive.
Furthermore, while sync errors were rare, they did occur but without any graceful error handling; a page might just fail to sync for no apparent reason for example.
Building a rock-solid foundation
The overload problem has been resolved now, so you should be able to import a Dropbox folder with hundreds of Markdown files in it without a problem. (It might take a while, but it will work.)
On the rare occasion that the Dropbox API fails to respond, or some other unforseen gremlin interupts a sync operation, it now gracefully handles that too by allowing you to view/edit the page, or try re-syncing it. There is no option to try turning it on and off again though...
Ready to scale
So with this update, I’m quietly comfortable that the system is ready to scale. By that I mean that meeting an increase in demand is simply a matter of allocating more server resources, not that in it’s current state it could withstand the onslaught the would come from hitting the front page of Digg, Reddit, or Slashdot. Of course, I won’t stop you if you’d like to put that to the test :)
One of the main benefits of Markdown is that it should be human-readable in it’s native format, but how often have you ended up with a page looking something like this:
* [Robert Herjavec: Top 10 tips for budding entrepreneurs](http://www.cbc.ca/news/business/story/2009/10/05/f-small-business-robert-herjavec-dragons-den.html)
* [Why you shouldn’t launch your startup in the press](http://gigaom.com/2011/12/19/lean-startup-launch-strategy/)
* [Slideshow on Customer Development Methodology](http://www.slideshare.net/venturehacks/customer-development-methodology-presentation)
* [You are in the emotion business](http://blog.kaisdavis.com/post/7877623196/you-are-in-the-emotion-business)
Human-readable? Not really…
The links above use the standard Markdown syntax of [title](URL), for example [Google](http://google.com), but as you can see, when the URLs are long, a list of links can become quite unwieldily.
Reference-style links to the rescue!
We’ve all read a Wikipedia page with the little reference links strewn throughout the document, and a list of links at the bottom of the page. Markdown actually provides native support for cleaning up pages using something similar. Instead of the standard Markdown link syntax of [Google](http://google.com), reference style syntax allows you to enter the link as [Google][1], and then place the link at the bottom of the page:
Go to [Google][1] to search for stuff.
Words, words, words...
[1]: http://google.com
You don’t have to use numeric references, the reference can also be a human-readable string.
Tools of the trade: Brett Terpstra’s Markdown service tools
If you already have a page containing hundreds of links using the standard syntax, there is a handy tool that can automatically convert them all to reference-style links for you. Brett Terpstra’s Markdown service tools for Mac include a “Inline Links to References” service which makes maintaining reference-style links a breeze!
After intalling the service tools, just select your Markdown in your favourite Mac editor of choice and select Services > md - Inline Links to References. Applying this to the nightmarish list of links above results in the following:
* [Robert Herjavec: Top 10 tips for budding entrepreneurs][cbc]
* [Why you shouldn’t launch your startup in the press][gigaom]
* [Slideshow on Customer Development Methodology][slideshare]
* [You are in the emotion business][kaisdavis]
[cbc]: http://www.cbc.ca/news/business/story/2009/10/05/f-small-business-robert-herjavec-dragons-den.html
[gigaom]: http://gigaom.com/2011/12/19/lean-startup-launch-strategy/
[kaisdavis]: http://blog.kaisdavis.com/post/7877623196/you-are-in-the-emotion-business
[slideshare]: http://www.slideshare.net/venturehacks/customer-development-methodology-presentation
Ah… much better! You can now maintain your list of links by entering them using standard Markdown syntax ([Title](URL)), select the entire document and then run the “Inline links to References” service on it to re-generate all the references.
Since installing this service tool, I’ve been using it to clean up my WikiPack pages. Hope it helps you in your Markdown workflow too.
