Every app should have a Save to blog function

Ross nails it! Every app (spreadsheets, SAP, wordprocessors, iMovie, iPhoto, iDVD, etc.) that can create any kind of content (text, video, audio, etc.) should have a "Save to blog function" that uses the MetaWeblog API today and the Atom API (when it's ready; unfortunately it is not ready today!). Heck "Save to Blog" should be an API built into the operating system just like "Save to File" is.

From WebGrabit v2.0 Imagined:

QUOTE

There is one last bit that would make WebGrabit a killer app for me - give it a "Publish to Blog" function that would allow me to take any bit of text from the WebGrabit RSS Desktop Component, format it, edit it, add to it and allow me to save it directly to Random Bytes as a weblog post.

UNQUOTE

Comments

Roland: Tons of apps already have a built-in "save to blog"... it's just labeled "send via email" or something similar. :)

agreed but since they use email that means they don't support categories and other blog specific features

like the browser, email is your best friend for blogging because it works with everything everywhere

and like the browser email is your west friend for blogging because it soooo lowest common denominator that it doesn't support things like categories

aaarg i mean "worst friend" NOT "west friend"

Right on! It cannot be that hard- it works like a charm in ecto (desktop blog editor) and flickr.

Roland: That's the thing, though... from my POV, there will always be something that will be unavailable in a generic app.

For example, yeah, I can post to my blog via w.bloggar or Newzcrawler, and I can attach a category in the process. But that leaves at least a half-dozen other, JournURL-specific features that I *can't* control... polls, per-entry templates, etc.

And then there are the more subtle things, like variability in markup. If I post something using the native editing environment, and then make a post using a theoretical blog plugin for Word, there's an excellent chance that there will be enough difference in the structure of those posts' markup to make them behave differently when displayed together on my index page.

When you put those factors together, I'm likely to spend quite a bit of time logging in and making changes to any entries that are posted from "foreign" apps. And that's probably going to be true for anyone using a "non-commodity" blogging tool or service.

So if I'm going to end up editing things anyway, why not simply take advantage of email's ubiquity?

And note that the situation gets more extreme once we move from the desktop to a mobile device. Even if a Metaweblog/Atom client were available for my phone, I wouldn't use it... when I'm tapping out a message on a tiny keypad, the last thing I want is an additional chunk of UI for setting categories. I want to snap a photo, punch in a text fragment, and hit "send". I'll save the heavy lifting for later, thanks. :D

As you may know, Roland, the "Post to Anything, Anywhere" capability is what we have built into Qumana over the last sveral months.

It now has "post to Blog", "post to email", and "post to integrated systems" with the capability of assigning Metadata. After collecting the microcontent and creating a linked tour, the content is posted to a WP Tools editor, with spellchecking, etc., etc. and the content is all stitched together neatly.

The content, after editing, is posted to blog or wherever and actually looks like a real grown-up professional post.

I believe Fred and Victor have been talking to you about helping to manage, or managing, our beta users forum ?

It's probably time for you to see the newest version ?

As you may know, Roland, the "Post to Anything, Anywhere" capability is what we have built into Qumana over the last sveral months.

It now has "post to Blog", "post to email", and "post to integrated systems" with the capability of assigning Metadata. After collecting the microcontent and creating a linked tour, the content is posted to a WP Tools editor, with spellchecking, etc., etc. and the content is all stitched together neatly.

The content, after editing, is posted to blog or wherever and actually looks like a real grown-up professional post.

I believe Fred and Victor have been talking to you about helping to manage, or managing, our beta users forum ?

It's probably time for you to see the newest version ?

jon: i'll believe it when i see it :-) until then it's vaporware and yes i want to help (coz I don't really think it's vaporware) and i am meeting with Victor to discusss this tomorrow

Personally, I like "Print to Blog" better.

People understand installing a printer, sending something on their screen to a printer, configuring page setup and printer settings.

And printing is available to all applications without customizing them. Printer drivers are well understood by programmers so it should be straightforward to build them.

Each of my blogs should look like a printer.

What do you think?

Hi Phil:

i don't care what you call it

'print to blog', 'save to blog', 'post to blog', whatever

as long as i can do it from every app where I create content!

I agree with you, Roland. It's just an architectural choice.

The distinction lies in where where you put the intelligence and code. SaveAs is a function created and operated by each application's developer. Adobe Photoshop had to license format converters from a number of vendors and patent holders to enable its SaveAs and SaveToWeb functions.

PrintTo, on the other hand, is an OS service available to all applications, even ones that have no idea what printers you've installed, or what rendering engines they use (Postscript, HPGL, Clearview, etc.). So every application that can print in your OS should be able to write to the web.

Fax software does this. I've also seen printer drivers that stripped everything but the text and wrote it to a .txt file.

hi phil

print to blog works as lowest common denominator 'good enough' that can be deployed today

and 'save to blog' using the blog specific features of the MetaWeblogAPI is also 'good enough' for deployment today

and hopefully in the near future 'save to blog' using the "hopefully useful and soon to be standardized' ATOM API will be 'good enough' in the next year or two

Maybe a way to go is install the print/save/post to blog driver as part of the operating system much the same way as many PDF add-in work. Thiw would enable any app to blog it's output.

I cannot wait for this new feature to become available.

Nice site. You are doing a great service to the web.

珊瑚カジノ

Add new comment