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.
