tantekthat's the usual explanation / justification I've seen. I disagree with the conclusion because it is design by only a particular context, and not the most important one
tantekwhich is the why the "back to the future" error is a result of tunnelvision design, obsessing over one particular "view" (the reverse chronological list) as opposed to what experiences readers actually have by time frequency
tantekyou cannot impose reverse-choronolgy on the reader, that's the point, not only can you not impose it, they are more likely to find your pages via search and external links, e.g. from our wiki
tantekeven if you *try* to use reverse-choronolgy everywhere in all your lists - it won't matter, search (people using Google/Yahoo etc.) will lead people to permalink pages, not your lists
KartikPrabhutantek: yes and on permalink pages "newer/older" as words provide context but on feed pages like the one I have they follow the usual reading flow of the feed page
tantekKartikPrabhu: you coming to IWC? agree with nav being challenging - I sketched what I wanted a few years ago and it fell too low on my itches list to get implemented (yet)
csarvenKartikPrabhu I don't see a particular issue with the way you have your new/old. The context is clear enough (for me). Although this is not the same, here is my archives page in reverse chronological order http://csarven.ca/archives/articles . I do not use new/old/prev/next.
csarvenI disagree with "KartikPrabhu no. previous = previously read/seen". Unless there is some sort of a tracking going on for that particular user, I don't see how that holds.
csarvenKartikPrabhu In order to declare the semantics of your prev/read and next/to be read, you have to introduce the variables which explain that context. I think the simplest context (in the absence of some additional information), the articles/events speak for themselves because they have a timestamp.
tantekKartikPrabhu: you're assuming there is one reading order - there isn't - that's the problem I've tried to point out from the start. especially when readers find and read pages via search
csarvenRegardless of the UI, the entries have a timestamp which indicate what is before or after i.e., which entry came first and what is next. Time flows in one direction (as I understand it) :)
csarvenKartikPrabhu Like I said, if you want to deal with it from the point of the user's past behaviour, you have to introduce that information into the UI somehow. And, that overrides the timestamps on the actual events. This is perfectly fine. However, it is an extra step - nothing fundamentally wrong with that in my opinion but tihngs could be misleading if the UI is not clear. On the other...
tantekKartikPrabhu: there is no one "readiing order" per the point about how people land on your (typically permalink pages), therefore it is an error to design derivative UI elements accordingly
tantekthere is however one sequence to the timestamps on your posts, therefore it does make sense to design consistent UI accordingly, consistent with textual information you already have visible on your posts, pages, lists, feeds.
KartikPrabhucsarven: yes agreed. I think having timestamp together with time-directional words like "newer/older" is better that any assumed "left/right" directionality
csarvenKartikPrabhu If you talk about your proposal by including lets a session property, I think it'd be more clear. That property=value (where the user is/was/may go) is entirely absent from the raw content on the page. So, I would still say that basing the UI around visible/available content is safer/more valuable than any assumptions.
csarvenAlthough this needs some work, I am now integrating slides directly in the articles e.g., see http://csarven.ca/this-paper-is-a-demo and click on the top-right menu, then "Shower". It enters the slideshow mode. :)
csarvenHmm, I'm not sure which issues in particular, but I htink it had more to do with h-event/h-calendar i.e., not being able to have multiple calendars on the page.
csarvenI also remember Glenn (I think it was him) experimenting with my resume in one of the newspapers? Perhaps Guardian's CV resume view. Hard to recall exact names right now.
csarvenif not already possible, it'd be cool to be able to update the mf/iwc wiki pages via IRC/Loqi. "Loqi Update http://example.org/foo#bar 'Hello world'"
LukasRosHey everyone, not sure if I’ve just been absent from the chat for too long or if it’s the extreme heat outside but I had trouble remembering the name of the IRC client I have installed :o
lukasrosenstock.netcreated /phpADNSite (+496) "Created page with "'''<dfn>phpADNSite</dfn>''' is an open source software that allows [[App.net]]Â to be used as a backend for a personal IndieWeb site ([[PESOS]] approach). It has been developed b..."" (view diff)
lukasrosenstock.netcreated /CloudFlare (+2423) "Created page with "'''<dfn>CloudFlare</dfn>''' is a service to, in their own words, "supercharge your website". Essentially they provide a distributed DNS service and CDN that acts as a caching rev..."" (view diff)
KevinMarks__A thought for Tantek and Kartik: if you make newer up and older down on your note pages they will match the feed view - otherwise you are arguing about rotation direction
LoqiNeoCities is a free website hosting silo in the spirit of defunct silo GeoCities (Yahoo shutdown in 2009) that looks like a stepping stone to getting started on the IndieWeb https://indiewebcamp.com/NeoCities
tantekis now wondering what he or his code would/should do with a custom style on a "like" post, especially if in the middle of bunch of other likes...
tantekParzzix, I'd actually recommend against starting with any backend scripting languages, the reason being it gives you tail-wagging-the-dog perspective of web development.
tanteklooks like I need to switch my permalink pages to use <body class="h-entry"> to make custom post styles work in a data driven way that can be re-used as a scoped style.