Thanks for your question.  A blog in Solve360 describes a web page that tells a story about something your team is working on.  A private diary/agenda for a business transaction or project, if you will.  We envision that most of the time a blog will remain private, used internally by your team, however publishing a blog to an external user opens up a whole new world, enabling you expose a specific view of your internal activity with your customers.

A common way to view a blog is as a “war room” where a specific project’s plans and activities are coordinated.  Many companies have multiple projects going on and blogs are an easy way to organize each one on a single page while still being able to relate the project to other items, track next actions, schedules, search, etc.

Here are a few examples to illustrate some common scenarios of how publishing can be used:

LAWYER publishes a blog to an external consultant to share the plan and related assets pertaining to a specific case/docket

COMMERCIAL REALTOR publishes a blog marketing a large property and its related business case to a select set of clients

HOME BUILDER publishes a blog to share the mutual plans/schedule of a specific home with its buyer and get feedback on issues as they occur

FINANCIAL PLANNER publishes a blog to a client to document the annual plan they agreed to

SOFTWARE DEVELOPER publishes a blog to a client to get feedback on the program specification and testing results

DESIGN COMPANY publishes a blog to a customer to document the progressive feedback on each design iteration

HOSPITALITY publishes a blog to an event coordinator to inventory the services needed and manage issues as they come up

RECRUITER publishes a blog to a client listing requirements, potential candidates and document the feedback through the selection process

You will be able to try an early version of the publish feature out as soon as next week.  External users are assigned Read-only, Modify, or Comment-only access.  Comment-only allows external users to add comments to each of the activities on the page, but not change the activities themselves.  Soon after that we will extend XML/RSS features so users can “subscribe” to these pages and get automatic notifications when something is added (similar to how traditional blogs do now).

Does this help?

Thanks for your reply, that does help. So the blog could act as a self-contained thread pertaining to a subject, thus keeping the correspondence separate from email and easy to view. This could work as a business tool, providing a log relating to projects.

I do unfortunately have a reservation before going down this route. I find most blogs get “congested” will fluff and dated information. I always wish drop down field(s) were available to tag blog comments according to different criteria.
Example tags could be : resolved / unresolved / greeting / key factual information
or maybe : editor comment / designer comment / new copy / key factual information.
or maybe : platitude / real comment
I think this would help address the biggest weakness of most blog chains, being that they cannot be filtered.

The Design company example is interesting. In my experience, an account handler usually updates the client – and internal team if your (un)lucky – through email. A filtered a blog workflow could be better, as the traditional approach has failings, because the whole team are unable see a detailed progression, and track the stages of a project. Project management therefore tends to be top down and input into the client correspondence is bottle necked.

If instead, through Solve360 all the members of the team could blog their input at key stages in the design and production process, that would be a radically different approach. It could also be a refreshing way of working for many publishing and design studios.
Assuming I implemented a blog management approach, I still see the progress of the layout and graphic designs from the studio being translated into pdf files and sent for client approval via email. However, the summary of the job could be contained within a blog, rather than each separate email. Maybe, the pdfs for review could be located on an ftp site - blog details regarding document status could link to these files.
For useful info on pdf workflows see : (http://help.adobe.com/en_US/Reader/8.0/help.html?content=WSA1FDD3D2-5A59-4c54-9E6C-8E511C277501.html)

As an aside…
My favourite *Published blog* is the Guardian website. I like this format because the article provides a consistent focus for discussion, and a moderator deletes anyone who is off topic. I wonder if this format could also be an interesting approach for internal approval process for marketing/journal copy. Beware faint hearted…bloggers do tend to slag off the author quite extensively.
http://www.guardian.co.uk/commentisfree/2008/aug/27/davidmiliband.ukraine

(thanks for providing me with the facility to update my post)

Thanks again for the insightful points of view.

In your example you would just post the PDFs on the blog, with surrounding commentary as required.  You see, our “Blogs” are different than those popularized for distributing news, most of our focus is on using special entries such as notes, task-lists, files, photo-lists, events, websites and linked emails to “tell the story”, content can moved around the page as the story evolves and comments are inline not at the end of the page.  So to “contain the thread” all of the assets should be there too.

Your thoughts about extending comments with different tag/status etc is interesting and we should explore those options as we learn more about how clients are utilizing this new feature.

Thanks… I will try to sketch out a flow diagram of how different parties could interact with information processes in the blog.  My concern is ensuring a single set of pdf files are referenced by all parties, avoiding duplicated input, or confusion.

Another type of filter that might be useful would be tagging the actual blog content itself (say with H1,H2, H3). Then if all parties know that key information is to highlighted (H1), then maybe the blog could filter to only show H1 text. This would be useful if half a blog entry is talking on topic and the rest is about what I had for breakfast.
(Just an idea, not sure if this is technically feasible/desirable)

Upon publishing my project blog, the invited collaborator is sent an email - this allows them to click through and view the blog. The view presented to the collaborator shows the title of the blog, messages, files, etc.

However, they do not see the description written about the blog, which I think would be really useful. I see myself taking responsibility/moderating each project blog I publish, and would prefer to “mark my scented words” at the top of the blog. Preferably in big letters, as typed into the background field.

Is this possible?

You are correct, some fields are not intended to be “published” (e.g. ones that disclose sensitive internal information such as related to, categories etc.) but Background should be there.  I’ll get taken care of in our next update (should be later this week).  Thanks for pointing this out.

The Background field is now being displayed correctly on a published Blog.

Nice one, thanks very much for that. 

I am testing adding comments to a blog. Comments added by both myself and a non-Solve360 email account.

It works and we can both view the blog. However, as the non-project blog email has no Solve360 user name their email comes up in the comment description. This makes for a lot of characters which overlap the comment text. Maybe if I could select the persons email from my address book so that they appear listed a name in the descriptor rather than an email address.

You’re welcome.  I think we can address the overlapping text.  We will likely add a lookup feature to the email address field which would use the contacts list and copy the name for display as soon as we complete some of the additional features we are currently working on.

Floydie - Sep 12, 2008 08:18pm

This makes for a lot of characters which overlap the comment text.

Sorry, forgot to follow-up that this issue was corrected last week.