@cleverdevil If you're going to do a tweetstorm, then you should do it so that you still own all of the content at the end. http:/
Aggregating it at the end for easier reading isn't just a bonus feature.
I've written a tad about tweetstorms as they relate to journalism and better aggregation which covers some of this area too: http:/
@kevinmarks I was recently reading about the relatively new AuthaGraph map projection, which I thought was both an interesting tool and mathematical toy. http:/
While I bought one to play with, I still like my globe much better--at least until my map becomes the territory.
UX/UI Suggestion: Meta box in the admin UI with PressForward metadata and comments · Issue #902 · PressForward/pressforward https:/
I'd suggest that it would be worthwhile and convenient to have a meta box in the admin UI for editing the final draft that contained all of the pre-existing PressForward metadata.
Bits and pieces of it appear in other portions of the PressForward UI throughout the vetting (reading, nominating) process (typically hidden under the "info" button which pops up the details), but having portions of it while actually editing the draft of the post would be very handy/useful. In particular, it would be nice to have access to the comments which are added to the particular piece in the earlier parts of the process.
@mathewi Despite her tweet about family obligations, I would more strongly suspect that Conway didn't want to be front and center as a target for having promoted Ivanka Trump's company earlier in the week after the Nordstrom story.
Either unnoticed or unreported by others, it appeared to me that Stephen Miller's appearance on Stephanopolous was primarily him reading all of his statement (fka responses) to George on a teleprompter in front of the camera. If you watch his eyes, they focus just below the camera and they're obviously making seccadic movements as he reads. His response also seems unnatural when Stephanopolous tries to break into his pre-written speech. At one point in the exchange Miller says, "I'm not going to make a comment on that." which I take for him to mean "I don't have anything written on my prompter that covers this."
One of the other journalistic issues that is often missed is that staff appearances in interviews should occur live and in-person rather than remotely via camera. This would greatly improve journalists' ability to break into the long fluff statements the administration tries to slide through as it's harder to interrupt over a multi-second delay. It's also more difficult for them to read canned statements like Miller apparently did.
I'm not seeing the HTML export on the desktop version of Kindle (from 2015) on my work laptop at the moment, but I'm positive it's hiding somewhere on my desktop machine, which is currently out of commission for some quirky problems. When I get it running, I'll try to document the feature as I don't think I've seen it mentioned anywhere else and it was tremendously easy and helpful.
I hadn't tried Bookcision as I'd stumbled across what I supposed was an easy answer, but there are a few edge cases for non-Amazon books in my collection that might benefit from using it as Amazon doesn't always play well with content that doesn't originate from the "mothership".
A while back, I'd bookmarked http:/
For general file conversion you might appreciate Pandoc: http:/
There are also some in the community who have tools (like Kevin Marks' http:/
Finally, I liked the teleprompter.css hint for marked2, but if you've not come across it, I often read newspaper, magazine articles, and fiction on my mobile using RSVP-related technology (Rapid Serial Visual Presentation) which has been patented (though I'm not so sure it's enforcable) by http:/
I think the biggest hurdle to wider adoption is simply the fact that there are so many individual plugins and this takes up far more mental space for the user than it should.
So, another option which I'd like to suggest and advocate for is to **bundle all the plugins into one big single plugin** instead of sub-plugins. You could almost sell it as "the part of WordPress core you always wished you had" and now you can with two clicks: download and activate. (That's got to sound good, even to your mom who's still figuring out how to upload her profile picture.)
From the user's standpoint, this wouldn't require much more than some slightly better UI/descriptions. (And I'm more than happy to write them.) This could consist of a single main settings page with on/off toggles for Post Kinds, Syndication Links, Webactions(?), Micropub, Hum, and IndieAuth. A tabbed interface on this same page with tabs primarily for settings/set up and usage description for all of these (except for maybe Webactions?) would complete the cycle.
Most of the sub plugins don't have many (if any) actual settings other than installation/activation right now which is creating the biggest part of the (mostly mental) hurdle for every day users. I think the average WordPress user probably wouldn't know that they had Webmentions, Semantic Linkbacks, or Webmentions for Threaded Comments installed because they "just work", require no configuration, but are far prettier than any of their predecessors. Why make them carry the mental overhead of what they are and what they do aside from a few subtle lines that they exist? In fact, treating them as if they should have been in WordPress core all along may actually make it more likely to happen.
Additionally things like Micropub which would only have an on/off toggle wouldn't be noticed or used by many unless they had interest in alternate posting interfaces. (And based on the popularity and growth in Twitter interfaces/apps a few years ago, I'm surprised WordPress didn't do this, though perhaps it's part of the reason they're adding a more robust API over the past few years?)
It also means having slightly better or more intuitive explanations of what the individual pieces are (mostly Syndication Links and Post Kinds) near their on/off toggles to better explain what is being activated. Much of this can be taken from the current interface or from the WordPress wiki pages, or added on the individual tabs for the settings for these portions.
I would suggest that doing this would not only make it easier on end users who then wouldn't have to spend the mental space and capacity to keep track of what 10 individual plugins are doing (in addition to the space these take up on the plugin admin page and the fact that, once activated, they disappear from the IndieWeb plugin's list of plugins), but that it would actually dramatically increase the uptake of the single big plugin and its functionality and simultaneously the use of the all the sub plugins individually.
I'd argue that bigger plugins like Yoast SEO or something like PressForward have huge numbers of options and settings and could have been done as separate sub-plugins (the way IndieWeb Plugin is now), but that their value proposition is such that it's well worth spending the handful of minutes reading through the interface to know what the options are, what they mean, and using them to their fullest advantage. I think that Indieweb (and the suite of tools offered on WordPress) is at this tipping point in terms of offering must-have functionality for the future web and that having a simpler integrated set up would help to push it over the edge to broader adoption. (Certainly simpler than the old WP-Social, which users have indicated that they thought was far simpler than Indieweb plugin, though Social actually required more set up.) Additionally all of the seemingly dense text in the "getting started" page could be moved into smaller bit-sized chunks relating to individual portions on a tabbed-interface, for example.
I come to this in part after having spent part of the weekend revamping a bit of the IndieWeb.org documentation on getting started with WordPress and setting up Bridgy with WordPress. A lot of the description is "get this plugin, install, and activate" which takes up a big piece of mental space for the user as well--particularly for the Gen2, 3, 4 users who want a plug and play experience. Far better would be to install one plugin and then modify these handful of settings.
If this is done, then the only remaining (small) hurdle is making sure that the underpinning rel-me data input required of the user is done in a more explicit manner, because this seems to be the lynch-pin holding a lot of it together and making it work. As a result, I'd recommend unbundling the reliance on the User Profile page and put all the rel-me URL fields on their own page in the settings interface for such a single plugin (with all important links just underneath them to encourage users to visit, for example, Twitter's edit profile page to include their website URL in either the website field or in the bio field to enable the bi-directional rel-me.)
Finally a "Tools" tab in the settings page could provide pointer links to additional things like the H-Card Widget or the IndieWeb-PressThis bookmarklets.
When all of this is done, it could also be a simple manner of adding another settings tab to the interface to set up Bridgy with one button links from the plugin to the set up pages for each of the main backfeed services there. Bridgy then automatically checks for the webmention endpoint and checks for rel-me to do it's work, so that part is already automated and relatively user friendly too.
The one caveat I can imagine is that making it all into one big plugin potentially means some small added overhead in development with maintaining some of them as stand alone pieces. I'd recommend keeping them as standalone objects as I honestly believe that pieces like webmentions and micropub are so fundamental to the web, that they should be part of WordPress core and maintaining them separately could help speed this along.
@ajspadial Awesome! Is your notebook accepting webmentions for collaboration too? I think of my site as a commonplace book/research notebook (as well as other things) and often bookmark journal articles I want to read. I'm slowly planning on using it to capture public notes, highlights, and marginalia from my reading as well. I use a private back end to write and revise as well.
@indiescripter I think you've probably got a pretty good start on the IndieWeb philosophy. And an even better start in that you're writing your thoughts on your own website first and then syndicating them to silos like Twitter.
I think that part of what you're missing about being able to reply to Aaron's original post is that his site both sends and accepts a new web protocol known as Webmention (http:/
I know Aaron also often syndicates copies of his posts to Twitter. There's another IndieWeb related service known as Brid.gy which bootstraps webmentions onto Twitter (in addition to other social silos) so that replies or comments to the copy that got syndicated to Twitter also send copies to the original post. In this case, he only syndicated it to news.indieweb.org, so it was less simple for you to have interacted with his post because there wasn't a Twitter version for you to interact with.
You'll find that within the broader community that different members will support varying levels of functionality (based mostly on what they're interested in), so someone like Tantek (tantek.com) will post on his own site and syndicate to Twitter, but he doesn't yet display webmentions. You can, however, post your replies to him on your own site and syndicate them to Twitter (perhaps using Brid.gy publish?) to reply to his syndicated copy on Twitter where he'll see the notification of your reply. You yourself serve as another example as you don't (yet?) offer a comment field on your own post. Perhaps you may never, but that's your choice. (I'll mention incidentally that many static website owners are using Aaron's Webmention.io for sending/receiving webmentions, see also: https:/
I think that a lot of the goal is to not only have fun with what you're doing on your own website, but do things which you find interesting/useful for yourself. Are you interested in locations/check-ins [http:/
Just be careful, because lurking in IRC or browsing the IndieWeb wiki for a while and seeing what others are working on or doing can make you very "itchy". Though the reverse is true that seeing what others have done (even how silos have done things in the past) can make it easier for you to build it not only better, but perhaps more quickly. Perhaps the CMS or language you're using is being used by others in the community [http:/
Keep up the search, and let us know if we can be of further help/assistance.
@Chronotope Okay, so I've spent the majority of my time since your tweet playing with (read: drooling over) @pressfwd.
It is awesome and almost exactly what I've been looking for for ages without knowing it. I think that I'm not only an immediate convert, but an evangelist.
In fact, not just hours earlier in the day, I'd made this comment on the WordPress Reader Refresh (at https:/
"Some nice visual changes in this iteration. Makes it one of the most visually pretty feed readers out there now while still maintaining a relatively light weight.
I still wish there were more functionality pieces built into it like the indie-reader Woodwind.xyz or even Feedly. While WordPress in some sense is more creator oriented than consumption oriented, I still think that not having a more closely integrated reader built into it is still a drawback to the overall WordPress platform."
From the sound of your tweets and how I see it laid out, in some sense I suspect you're personally almost also using it as a built in bookmark or to-read app like Pocket or InstaPaper? This is almost exactly the type of "off label" use case I'd like to bend it to--though it doesn't really require that much bending given its current architecture. Are you displaying all the items you've read/commented on publicly (and where is it?) or are you just using the comment functionality and the nominated portions as a private "I've read this list" on your back end?
I've been thinking about the topic for a while since just before InstaPaper's acquisition by Pinterest and recently written a few things including about Owning My Online Reading Status Updates: http:/
I've even thought about using the Wallabag self-hosted version of something similar to this, but I'd prefer something more closely integrated with WordPress and PressForward has almost everything one could dream for.
If you have a few minutes next week to chat via phone about some of these uses, I have a feeling you could expand your user base a bit as a result. I also know of a few folks working on similar WP-based readers who might be encouraged to merge their work into your much more polished project.
My thanks to the whole team for not only a beautiful plugin, but for some well written and spectacularly documented code on Github!
Settings UI/UX feature requests: Ability to globally auto-set post publicly/post to self · Issue #4229 · hypothesis/h https:/
Perhaps it exists already and I'm not seeing it, but most of what I highlight and annotate, I typically prefer if it were automatically published freely and in the open. Currently it appears that highlights default to "only me" after they're highlighted. Annotations appear to default to public initially as they're being written, but when re-entering the text without manually hitting publish, they then are posted automatically to "only me".
This may be a reasonable default, but it means spending more time with the interface while I'm reading/working and thereby taking me out of the flow of my work.
Unfortunately, there is no default setting for forcing my highlights and annotations to be public, which means when I'm done reading that I have to go into the UI and manually do three button presses to make this happen for EVERY post. Click to edit, click the setting arrow, and finally click to publish. UGH!
In addition to allowing a master setting toggle for public/private at the main account level which would alleviate a large portion of my issue, I'd also recommend that rather than a drop down menu with two options that there just be a simple toggle to switch between public/private on each post so the user can accomplish in one click (or fingerpress on touchscreens) what currently takes two. Admittedly it's also controlling a "publish" function simultaneously, but I think that each post could have a public/private toggle and a separate "publish" button without cluttering up the UI too much.
julzybee73 If you're interested in apps for researchers, teachers, and students, you might also consider looking at additional apps like Diigo, Mendeley, and hypothes.is (for highlights and annotations). For bookmarking sites, there's a pretty good list here: https:/
UI: Duration doesn't make sense in Read post kind · Issue #65 · dshanske/indieweb-post-kinds https:/
When making a "Read" post in which data exists in the "time" tab for published dt and updated dt, the output displays more like one would anticipate with a music post type (or jam, listen, play, watch, travel) using start/end vocabulary instead and outputting a "Duration".
Duration may make sense if one were doing a start/end time for their reading, but then the scraper shouldn't be automatically pulling in the publish/update dates/times. Personally I'd prefer to let the publication time of my post indicate when the thing was read and have Post Kinds indicate the publication of the original piece I was reading.
Possibly better would be an if/then statement to differentiate types and for Read types outputting a date/time for the original publication and/or potentially an updated date/time if it exists.
At present, the issue is most common on New York Times posts for which the scraper pulls in the correct metadata.
Example: http:/
