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?
