gRegor`Might be a mix of html and plaintext. I can move to plaintext, though I can imagine some scenarios where I'd rather use a title as the link text, not just the URL.
gRegor`My wm support was set up based on the CMS, so initially i only accepted them to valid post IDs. When I added the notes as a plugin, though, I realized i needed to open it up to more paths.
glennjonesjeffporter: /webmention/mention/forward/ return 200 from your wordpress plugin to say the request was a success, so the mention should now be in your comments list for that post ?
jeffporterglennjones: Yes. Going to work on adding them back for Status posts, maybe others. Integrating Web Intents on Status posts is my biggest stumbling block at the moment.
gRegor`, pfefferle_ and KevinMarks joined the channel
gRegor`But then there's a 'Notes with photos examples' section "Not quite photo posts, but similar, notes with embedded photos are another approach to photo-like posts."
kylewmgRegor`: the distinction I use is that notes and articles can embed arbitrary images, but photo posts have a specific layout where it displays a small version of the image with a link to the larger version of the image
mkoThe way I understand them, "Photo" vs "Note with Photo" are pretty distinctly different. A "Photo" post is basically a photo without any other content (i.e. photo filename = e-content, p-summary, p-name, u-photo) or where the photo is the entire e-content (and u-photo) accompanied by a p-summary / p-name. A "Note with Photo" is a note post that includes a photo referenced in the e-content that is attached and marked up as u-photo.
gRegor`Then I think this is a photo post, though the text isn't explicitly intended as a caption, but rather my commentary on the photo: http://gregorlove.com/notes/2014/07/15/2/
gRegor`Since my notes always have the text content as the p-name, all I have to do is add a u-photo and it's a "photo" post. But it's also a "note with photo" :)
mkoI'm using the raw h-entry JSON format as my base class for all posts right now, and I've not had to add anything extra except for a few metadata fields that I'm using that aren't actually needed but power some minor enhancements on my site (i.e. reading time, word count, character limits, etc)
mkoI consider "entry" to be my base class, in reference to h-entry, and a "note" is any "entry" that uses the same content for e-content, p-summary, and p-name.
kylewmin re to bridgy, note vs. photo distinction is interesting w/r/t POSSE ... if the image is the primary content or just decoration (in which case you might not want to posse it)
mkoKartikPrabhu: I don't think we're "strictly classifying" -- I think that's why this discussion is even happening. The nice thing is that if you want to not extend the base class of "entry" (or "post") you never have to. If you want to, you can do so for whatever purposes you want, though you should realize that not everyone will necessarily do the same.
gRegor`I agree on the strictly classifying. I'm more interested in whether there's supposed to be a different mf2 markup than whether my interface is strictly "post an article/note/photo/whatever"
mkoThink of it this way: on Instagram, you can post text content with your photo, but the primary content is the photo. On Twitter, you can post text content with your photo, and the primary content is the combination of the two. I would consider the post on Instagram a /photo post while the post on Twitter would be a /note post in my mind.
gRegor`KartikPrabhu: You're right. I was mixing up presentation with markup. I haven't done so yet, but I've set up my notes so they can have a (displayed) title, not just the text as the default p-name.
mkoAnother example, from my own experience. I was the design lead at hi5. We did research into how users were using the Photos feature versus the Status Update feature (which had the ability to post a photo). Users posted photos without any text the vast majority of the time. When users posted status updates with photos, on the other hand, they almost never did so without accompanying text. On top of that, we found that when there was text
mkoaccompanying a photo in the Photos section, it was almost always a caption related to the photo (with very few exceptions), whereas those in a status update that would go on the Friend Feed typically was conversational and not directly related to the photo.
mkoWe also did research into the longevity of photos. Photos posted in the photos section would be deleted about 15% of the time over the lifetime of an account. Photos posted as a status update were deleted less than 2% of the time over the lifetime of an account.
snarfed[tangent: mko: you were at hi5? oh man, funny. i was one of the app engine founders, and we were all excited when you (hi5) bought buddypoke since it was our first user acquisition]
KartikPrabhumko: I am not disputing that there are lot of posts that fall into one criteria or the other. But there are also many that fall into none or all
mkoAnd I'm not disputing that. What I'm specifically saying is that if they don't fit into any of them, don't put them in there. If you want to classify something across all the different post types, do it. Ontologies are meant to be self-effacing. You make use of the classification system how you want to, and as the community evolves, so does the usage of that classification system.
KartikPrabhuat least on some pages which don't have clear-cut agreement there should be some clause saying "the current idea" or "current consensus" or soemthgin
kylewmgRegor`: does it help if you think about it from Bridgy Publish's point of view? look at an h-entry and automatically determine whether it should be posted as a photo or a note?
KartikPrabhuso again, is there some UX reason to have photo and note with photo and photo with caption different? Also author-UX and reader-UX both...?
KartikPrabhuskip all the HTML+mf2 talk... we need a definition similar to "A note is a post that is typically short unstructured* plain text, written & posted quickly, that has its own permalink page."
snarfedKartikPrabhu: well, kind of. we also have the bridgy publish use case. it fetches post html and wants to know, programmatically, whether to posse it with a photo or not (and if so, which one)
mkoNot in the HTML that's published, unless you're duplicating content by posting the contents of items[0].properties.name in addition to the same content that's in items[0].properties.content.html
mkoRegardless, it doesn't make much of a difference. What I had said before is not the same as that. I specifically said that for my definition of a photo post the e-content is wholly the photo while the p-name/p-summary is the text content.
mkoThat's how I defined them in my system, anyway. I can add photos to any post type in my posting interface, but if it's a "photo" post type, the e-content filed becomes a file URI instead that is equivalent to u-photo instead of any text content.
mkoh-as-note will have e-content and p-name the same ("Description of Image Description of Image" or "/path/to/image Description of Image"). h-as-photo will have different e-content ("/path/to/image" since the e-content is the same as u-photo) and p-name ("Description of Image")
mkoIn any case, my interpretation of e-content on an element is that you take its contents. For an image, that's the src value. For a div, that's the contents of said div. For a time element, that's the datetime property.
cuibonoboKartikPrabhu: this is actually perfect because i was interested in how stuff like indieauth and webmentions came to be. i imagine it was a process similar to this :)
kylewmI think that the suggestion to add "with an optional caption" to the definition is good -- and encompasses the idea that it's not just text but text that is in service of the image
KartikPrabhukylewm: re: your note with a photo example. If you were to post a photo with a caption, how would the posting UI differ. How would the reading UX differ?
kylewmKartikPrabhu: my photo posting UI is simpler... just select a photo type a caption, done. Posting a note has more options... you can upload arbitrary documents and link or embed them in the content
kylewmKartikPrabhu: on the link he just posted, the sidebar on the right has a list of tags, and below each tag is a link to the previous post for that tag
KartikPrabhupeople! I want to play with exporting ebook notes (marginalia) and highlights to my site. Now notes can be in-reply-to a fragmention but what are highlights? like-of or bookmark or favourite ?
cuibonoboKartikPrabhu: i stumbled onto your webmention repo on github but saw your note that you’re no longer using it. did you go back to vrypan’s or switch to something else?
KartikPrabhuok... is it the expectation that I make a diff UI for each sub note type? i get that Likes, Replies and Reposts are not that different from each other but then "Bookmark" and "Quotation" ?
KartikPrabhuok I am becoming convinced of the followin POV. if it is a repost/like only, then the commentary is meant for followers of the reposter and not the author of the original post. But if it is repost and reply then the commentary is meant for the author of original post. Present the comment accordingly