Future

Regarding names, you could auto-create blog entry names based on the creation timestamp, then if we implement aliasing, add a text name as well.

---

this doesn't seem like a dev ticket. making it an idea.

  --Ethan McCutchen.....Tue May 11 14:05:53 -0700 2010

---

 I moved a bunch of older exploration into the following.

blogging+solution+old

help edit space_dashboard

Blog entries:

any card (of any type) can be a blog entry

card name is title of entry

{ {+blogged to} } (Pointer checkboxes to blogs i have edit permission for), *options={"type":"blog"} (permissions just works?)

Want a one-click thing in sidebar/footer "Blog to: { {_main+blogged to|view:checkboxes} }" ? (_main is page's main card))



Blogs:

there's a blog Cardtype

Card name is title of blog


View mode:

main column:
search for X recently created cards w { {+blogged to} } this blog
|items:summary
page icons are permalinks
date/time created/posted visible - in card footer? card name hover?
comments (if allowed)

in page sidebar or footer:

Link/button to add new entry
(just an included +new blog entry card? Basic w link/URL that creates relative cards?)

Link to earlier entries (human-readable URL)

+blogroll

??


Edit mode:

How many items for front page

Allow comments? (if yes, can create/add to +discussion by each entry - not just yes, but usual permissions menu?)

Use created or modified date? (in latter case, don't include automated page name updates?)

(Look at WordPress; RSS for other likely stuff)

====

Features wanted for it (tag blogging):
generate feeds

(add pinging)
implement summary inclusion view
HTML from +cards (+taglist items -> Technorati tags)
card-specific sidebar/footer
URLs that not only create new cards but relative cards from them
_main refers to page's main card

============

Issues:

If i blog a card to a blog i have create permission on, then lose that permission, can i still edit the card later?

The main difference with the old suggestions is that they were focused on the possibility of making any card a blog. This would certainly be possible, either with a tag approach as proposed or by whatever query is desired. You can use the structure directive and format anything as a blog. Or you could include any card within the post, of course. I don't think that's a great default set up, because the added complexity buys little (in fact, I would suspect that blog posts that aren't written to be blog posts would tend to read awkwardly), but it will be wagneerable with the other stuff proposed, so folks will have the chance to prove me wrong (again).

 

Similarly, I think autonaming a blog post is a pretty bad way to go.  That's the headline; it really should be thoughtful.

  --Ethan McCutchen.....2013-04-05 15:39:40 +0000

---

there's also been advocacy to Implement microformats. To my mind the demand is low there, but, yet again, I could be wrong...

  --Ethan McCutchen.....2013-04-05 17:00:12 +0000

---

Folds - does enabling this for core view mean that it will be available in other views as well? yes - efm

 

Blog designers may want that flexibility. Re explicit folds, are we talking about new markup to indicate where the fold is? Something like ? (It would be nice to avoid adding a whole new category of markup besides []s and {}s.)

I don't have a proposal in mind yet.  maybe we should bat ideas around on implement folds?

Yes, copied stuff there.

 

commenting overhaul - you're thinking to just do the near term stuff for now, or...? In any case, unclear what you mean about metadata / #comments / #commenters 

I m not totally attached to this plan, but I think, yes, the current proposal was that "near term" would basically mean "before 2.0".  But if we like that plan we could do more.  By "# comments", I meant "number of comments".  For example, on facebook you frequently see a little link with the comment count in places where you can't actually see any comments.  I think that's valuable, but with the near term changes it's very difficult, because you can't query for the comments.  You would have to parse the content, which is unworkably slow.

Makes sense.

 

Dates - I think I agree on renaming. And yes it would be very nice to be able to format them. I'd add as a higher priority that we add configuration of site time zone. <-- any thoughts on this, Ethan?

well, renaming will probably happen first because it's probably about half an hour of work, it fits with other renaming chores, and the later we wait the more people we'll confuse.  but let's bang on the time zone configuration.  if it's easy, then yes, let's do it soon.  My gut feeling is that it will probably fit in with the other time formatting discussions, because it's all processing that will need to happen around the same time.  Though the time zone stuff may be easier to bake.

 

Automatically showing when a post was updated (if it's been edited since originally being posted) would be nice. Urgh, in reality people may edit it a bunch initially and want the last edited date to be treated as the post date unless/until they make a later edit. Not easy to handle, so probably wait on this til after 2.0. kottke.org handles this very well, e.g. http://kottke.org/13/05/updates-on-previous-entries-for-may-3-2013

I don't have a well -cooked proposal for this either, but I do think we're going to have to evolve a concept of "publishing" if we're to make Wagn a top tier content manager.

 

Yes, I think a module for social media is a great idea, implemented entirely in Wagn - i.e. not dependent on any of the many "share this" type webservices that do this (we or other people can develop modules that use those later if they like).  I would want to start by using a service, but it would be great if someone decided they wanted to take on a native module.  I'm basically not interested in any new maintenance tasks.

support social media sharing

 

Ideally the module would let Wagneers choose which social media they want to appear. I think it would make sense for this module to be included by default in new Wagns. Is there a list anywhere of currently-existing modules?  no, there's basically built-in stuff and client stuff.  I'm assuming we'll just start with this module built-in.

Makes sense. FYI, even a hand-maintained, incomplete list of current and maybe planned built-in modules would be helpful for me.

---

Re autonaming, there are many use cases for blog-like things where you don't want to have to come up with a title and wouldn't be displaying it. E.g., Twitter, link feeds such as delicious/pinboard. I don't think this is something we have to handle for 2.0, as long as we develop in a way that will make it hard to extend in this direction later. (And I'm not seeing any such issues so far.)

not sure I understand the flow you're envisioning, but pretty much everything we're proposing is "unbundled", so you could build lots of variations easily.

"Unbundled" meaning a module, not part of core Wagn?

---

Permalinks should be handled well. Making the title a link to the card should do it, and I thought adding a view for that was ticketed, but I can't find it now.

show: title_link now works on any view with a title.  (and you can set the title with title: whatever)

Eeexcellent.

 

It would be nice to have a good blog archive. Thinking out loud:

1. Extend WQL so that you can search for cards with *date created between given dates yep, maybe we add a make date ranges WQL-queryable idea and figure out how that would look?
2. Add code to the blogging module that returns a list of well-labeled links which go to searches (using 1.) for posts from each month, from the current month back to the first month that has a blog post (but only months that actually have at least one post - that may be tricky)

(copied this to solution)

---

There's also blog configuration to consider. Just for starters (I know these won't probably all be configurable, or even necessarily implemented in this go-round):

• the name of the blog (just the name of the card of type Blog I guess?)
  
• WQL for what cards are in the blog (defaulting to something like {"type": "blog post"}) - is this even how we're handling this? Gah, if there are multiple blogs do we need a new cardtype for each one?
  
• what layout to use for main blog page, for blog posts (could be different)
• feed URL (lots of people use external services such as Feedburner for their feeds)
• how many posts to show on front page

I had just pictured that there is a type called "Post" and some useful views (one of which can be a feed link).  You include a list of posts on your wagn where you want them.  Our primary tool for making WQL usable (to control what subset of posts you want, how many, etc) is going to be name chaining (+by name), so that's where we should put that effort.  A Blog type might be nice for discoverability (eg, teaching name chaining).  I wouldn't assume there'd be any special default layout; would work as normal.  Definitely do not want a proliferation of  types.  I would assume that a post would be associated with a blog or blogs via a +blog pointer.

So every time you make a Post card you have to fill out a field to tell it what blog to add it to? That seems clunky, I suppose it could be eased by having "add a post" links autofill that field, but it would still be weird noise to most people (we could CSS it to display:none). I imagine that we're going to keep running into configuration options specific to a blog but I may be wrong...

 

Would certainly be cool in the long term to be able to support whatever you call it when a page autoloads more results as you scroll down...

Added to the solution.

 

We'll want a configuration card for each blog if we are allowing multiple blogs - not an absolute necessity for 2.0 but it would definitely be nice.

a configuration card?   what's that?

It has the configuration info I listed above.

 

It strikes me that we may want new Wagns much like English for many modules, that's the easiest way I can think of for developing and maintaining the built-in cards sets for any module that involves a lot of built-in cards.

after 2.0 we need to put a lot of thought into how we want the module ecosystem to work.  2.0 will introduce the API, but not really the full community apparatus. 

Will 2.0 include the ability to install a Pack through Wagn or will it require server access? In any case, sounds like a module ecosystem support blueprint may be in order to start  tracking these ideas?

 

Author - I think we use initial creator only

is this in response to the virtual pointer content?  That was just an optimization; doesn't really change behavior; would not be editable.

Nope, just thinking about how/whether to change the author if someone else edits the post later.

 

Another thing we'll want at some point (if not for 2.0) is to alert ping services when a blog entry is posted. http://en.wikipedia.org/wiki/Ping_%28blogging%29 (this is now added to the solution)

I don't think this idea is spelled out on a ticket yet (maybe cursorily on a flexmail overhaul discussion?), but I want to get rid of the *send setting and add "*on create", *on update", and "*on delete" (and possibly *on read).  Then we would add a few wagneer-level actions that could be triggered by those events, like emailing and pinging.  The point is to unbind the trigger and the action.

Added this to upgrade email system.

---

Title as permalink is a little problematic because of rename. We don't have alias/references yet, but something like that would help with permalinks. more as a academic note than a viable solution, it's worth noting that you can use the ~id format as a link that survives a rename (and you can see the id with view:id).

---

Thanks for the feedback, guys. Gerry, there's a lot of related work on DeckoSystems and Hands of Cards. Could you move the non-blogging-related comments there?

 

John, I'm going to go inline with my responses to your comments.

 

 

---

Re title as permalink, I wasn't meaning a persistent URL through name changes - I think implement aliasing and then offering to leave an alias behind when renaming a card is the way to handle that. I just meant a view that is just like titled except the title is a link to the card. This would be helpful in contexts other than blogging as well.

 

We could have a single Wagn for all of the cards in all Modules/Packs. One upside would be that name collisions would be worked out there. That wouldn't solve name collisions if someone installs a Pack with cards that share names with cards they've added to their Wagn, but it would guarantee no name collisions among official Wagn Packs.)

---

Do Packs all come with a card of type "Pack" which includes info about the Pack, configuration options, a Pointer of all cards in the Pack. links to documentation, etc.? Something like the latter seems like a necessary part for the ticket Gerry wants to start, which I'd call add a way to load a Pack from another Wagn.This comment should really go there anyway.

 

They don't come with a card yet, but the plan is for them to.  See Packs+architecture.    Being able to load a Pack (with code) from another Wagn is actually at the intersection of Hands of Cards and [Packs]].  I think we want to build towards that, but it's tricky....

---

these ideas aren't ticket-ready. let's bang on the blueprints.

---

first sentence of Hands of Cards: "Hands" are just a group of cards made easy to copy from Wagn to another.

---

There seems to be a lot of confusion around modules, packs, etc. My vote would be to punt on most of those questions until after 2.0. Pretty much *everything* in Wagn that a user interacts with is already, in some sense, in a pack. Anything that isn't will be soon. By that we just mean that it uses the API and is theoretically removable from the core, which just abstractly handles cards, sets, rules, rendering, actions, etc.

 

At 2.0, we still won't have much apparatus around separating and re-integrating packs; the main value of the Pack API at that point is that we can build custom stuff to meet custom needs without having to alter the core.

 

Right now, to install a custom pack (one that isn't in the wagn codebase on github) on Cloudstore, we have to create a whole new Cloudstore accessory. That will be the case at 2.0. So all the blogging discussion is about what to offer wrapped in at 2.0.

 

By "unbundled", I just meant that we're talking about achieving good blogging behavior by building lots of functionality that can be combined to make good blogs, and then we'll wagneer a good default setup on English to make it easy for new wagneers to use. There will not be a discrete "blogging" module. At the very beginning of the solution, it says:

 

"I think by 2.0 we should have a built in "Post" type with solid blogging functionality (though I don't think any of it should be hard-coded; we should be able to wagneer the whole thing)"

 

So, AFTER 2.0, when we're ready to look into make it easier to move this kind of functionality around between Wagns, the main questions will not be about packs, per se; they will be about Hands of Cards.

 

John, the closest thing to a list of packs is to look at the code: https://github.com/wagn/wagn/tree/master/lib/wagn/set For example, if you click on "type" you'll see all the types that have pack code associated with them. Similarly, you can go to https://github.com/wagn/wagn-cldstr to see all the client packs (click on wagn-clientname, then files-ws to see the pack file itself). If you decide to make a written list, please don't make it public. This is a case where inaccurate is worse than nonexistent, imo, and I guarantee we won't keep it accurate.

---

Yeah, I'll move my stuff to the WagNet and Packs cards, and maybe John should do similar with the related questions he has.

---

since "bundle" has a real pack meaning (see Packs+architecture), I probably shouldn't have used the word "unbundled" this way. But do you guys get what I'm saying (poorly)? I'm hoping a Post can be a coherently wagneered assemblage of a bunch of standard Wagn functionality, not a separate realm of blogginess with a bunch of idiosyncratic low level code.

---

So if I understand correctly, "Post" will not be part of core Wagn, but will be in a Pack that is included by default in new Wagns? (as is lots of other standard funcitonality)

---

I don't know if there will be any "Post" code at all. I think it will just be wagneered on en.dwagn. But, right, if there's code, that's how it will look.

---

Hmmm, the automatic dates (created and edited timestamps that AR creates and updates for us) may not be sufficient to implement blog semantics. Probably should give entries an explicite 'pub-date' in a plus card to the blog entry cards, and use that to format permalinks. We need to separate the production workflow (how a blog entry or other published item is created by an Editor) from the publication process (Adding it to the public blog and feeds), and editing (fixing typos, renaming entries, etc.). Failing that, the creation datetime needs to be the source for permalinks.

 

---

 

Suggesting another need - improved feeds, in particular:

• allow specifying a feed URL for auto-discovery - the weak argument for this is that many bloggers use feedburner feeds. The strong argument is that blog pages on Wagn are rarely searches (which do have auto-discovery), but Basic cards that include the relevant search. E.g. Blog.
• validate (or at least make sure any failure isn't causing problems):
• http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwagn.org%2Fwagn%2F*recent_changes.rss
• http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwagn.org%2FWagn_blog_entries.rss

---

Advance warning: This is going to tangent a bit. It starts grounded in feeds auto-discovery, but ends up being about custom layouts, search divs, and some other things. We can move things to wherever makes sense when that's clear...

 

I realized we *could* leave it to blog-creators to make a custom layout for their blog to specify their auto-discovery feed. This led to the usual challenge with this, which is that from then on whenever you edit "Default Layout" you probably want to go and edit your custom layout as well. This led me to thinking about a general solution for this problem and an obvious possibility is to include a right form in Default Layout wherever you will want custom layout html on some cards. So on http://johnabbe.wagn.org/Default_Layout I added {{+header extras if any|core}} and then http://johnabbe.wagn.org/header_extras_if_any+*right+*structure is a search for any cards with left of _main and right of "header extras" with view set to raw. This works - http://johnabbe.wagn.org/Blog+header_extras shows up on http://johnabbe.wagn.org/Blog - but there are divs there that there is no way to get rid of. In the HTML they're inside the head block, but it seems like the browser's DOM pushes them(!) down inside of body, so if you try to CSS them to display:none it doesn't work (I tried, see http://johnabbe.wagn.org/*css ).

 

Here's what it looks like in the HTML:

      <div class="search-result-list">
                <div class="search-result-item item-raw">
                  <link rel="alternate" type="application/rss+xml" title="RSS" href="http://johnabbe.wagn.org/wagn/blog_entry_list.rss" />
                </div>
        </div>

 

This brought to mind add bare_items view which I think will remove the "search-result-item" div but not the others. This seems like a general thing, so I think we should have an Idea add a way to strip list and item divs from Searches - make sense?

 

Through this I also realized that it would be trivial for us to default to auto-discovery of recent changes feed.

---

Please let me know when you've checked all you want on my Wagn - it doesn't look too awful, but I don't want to leave it that way forever :-)

---

embarrassed to ask this, but what was I checking out on your wagn? sorry to have held you up.

---

The comment just above, which begins, "Advance warning"

---

(And the comment above that is somewhat relevant as well.)

---

Oh, you can change your site back whenever.

 

re the advance warning, I think the link you suggest is the same issue as (but a better name for) add bare_items view. It's a better name because it's a use case that we definitely want to support, but I don't really like the "bare_items" name.

 

the work around is to use CSS that sets those divs to display:inline. alternatively you could do this without a search, the +header_extras could just be a basic card but could have a different structure rule in different situations.

 

I think the feed discussion is elsewhere, no?

---

Renamed it, will have to come back to the rest of this later...

---

As long as we're talking about easy image insertion - easy file insertion (for both podcasting and in general)

---

isn't that different? you don't usually want to include a file in the middle of your content. if you want to structure your blog with attachments, that's already easy, no?

---

to say that a different way, adding cards to a blog's *structure* is easy. the issue is making it easy for folks to add images to the *content* of a blog post (or really any content). frequent complaint, fyi.