Wait, is it nearly June 2017 already?
As per this notice on the Dropbox Developer Blog, the Dropbox API that WikiPack uses to sync pages will be turned off on June 1 2017.
As of this moment, WikiPack has not been updated to use the new API, which means that Dropbox sync will stop working at that time.
Unless I'm able to re-write the app, update it to use V2 of the API and deploy it over the weekend...
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…)
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:
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…)
Firing off concurrent AJAX requests that update various parts of the page (the Pages & Faves sidebar panes)
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.
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 :)
Cheers, Mark
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.
~~~
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.
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
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.
Some apps just use plaintext emails, which is fine, because Markdown is plaintext, so no conversion is required.
Adding content to your pages is now as simple as sending an email. Here's how to do it in a few different apps:
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.
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!
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.
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:
Let me know what awesome ways you come up with for using WikiPack's new email to Markdown feature!
I’d like to share some stats with you:
~~~
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:
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.
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 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 offers two modes of API access to third-party applications:
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:
Now, click this link to view which Dropbox access mode they’re using. Mine looks like this:
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?
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.
What do you think?
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.
~~~
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.
In the video I demonstrate a couple of handy features of WikiPack’s Markdown editor:
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.
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.
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.
The response so far has been phenomenal!
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…
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!
As always, send any questions/comments to info@wikipackit.com, or @wikipack.
Thanks,
Mark
~~~
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 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 love organising their files into carefully named hierarchical directory structures. They know exactly where to look when trying to find a file.
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.
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.
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,
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.
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.
Getting in touch:
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.
~~~
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.
Getting in touch:
~~~
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.
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.
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.
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.
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.
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.
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.
Questions & comments:
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.
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!
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.
~~~
As always, please direct questions & comments to:
WikiPack has published its privacy policy at http://wikipackit.com/privacy.
In a nutshell, we will always treat your data as your data and always respect your privacy.
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.
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.
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.
Would love to hear your questions & comments!
~~~
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.
~~~
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).
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).
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:
~~~
Handy!
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.
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.
~~~
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.