-
play0:00 / 2:23
-
guyweb No speakers! Anybody want to transcribe this for me?
-
watershed I'm on the side of Jeremy Keith (http://twitter.com/adactio/statuses/1525683207) and Robert below. Aside from the issue of linkrot what seems perverse to me is the use of URL shortening in contexts such as Twitter at all. Textile and Markdown provide elegant ways to encode link text with a full href behind it without the need for the user to write HTML; and the syntax for these is no harder to learn than understanding the world of URL shortening services themselves. Just because Twitter carries so much weight doesn't mean URL shortening (outside of HTML email and referencing in print) is a good idea does it?
-
fauverjo I'll grant both sides a go - Paul, you're right to say that Twitter is time-sensitive. But, I'll also grant that for historical research there does need to be a permanence to the short-hand URL's we use in micro-blogs. I for one, would rather it be more universal than just Google's archiving of everything there is. This is the trouble with the speed of the tech-(r)evolution. But, since Robert has posed the problem there will, no doubt, be a good solution in relatively short time - most likely from the Open Source community.
- 2 more comments
-
-
play0:00 / 4:30Jamesglory likes this.
-
markmarcus As usual, an excellent Boo. Thank you. Mark Marcus
-
Jamesglory Brilliant! But i'm still lost! Blessings, james
-
-
-
-
play0:00 / 1:43
-
philcampbell interesting. ok. i'll put in some kind of refresh control so they can get to a new set.
-
JoelDrapper Great points. It's very annoying when you have to refresh a page multiple times to find the feature that caught your attention before.
-
-
play0:00 / 5:00Jamesglory likes this.
-
aerotwist I don't normally weigh in on stuff like this, but I have to say I disagree with this stance. I would agree that if you are building an HTML site you are best to use JavaScript to progressively enhance a server-side process. But that also fails to acknowledge that there are things that server-side processes and standard HTML simply cannot deliver. Two examples would be Google Maps and Flash sites. One could make an argument that these are not valid, and that because they aren't accessible - since they rely on proprietary technologies and not the most common denominator - that they shouldn't even exist. I think this fundamentally rails against the notion of the choice of expression that the web provides. Surely, yes, encourage people to not use a proprietary technology when the same can be achieved with accessible methods. But to say that all sites, no matter their use, audience or content should be delivered with server-side processes and HTML only (with bolt-on enhancement) is, I believe, flawed thinking. I would add a caveat here that if a site has been funded by public money for, say, a government site, I believe it has a duty to be delivered for the people who paid for it, which will actually mean building specifically for maximum accessibility. But to try and apply that stance, legally or technically, to all sites on the web has the potential to stifle creativity and freedom of expression.
-
Jasonholland Nicely said... a site built well degrades and still works. It's a 'quality' thing, not a budget thing.
-
-
-
play0:00 / 1:30Voice_of_Roldano likes this.
-
markjames Hi, I have just started following you and its going to be great to listen and learn from what you have to say? I'm interested in the world of social media. Would you be able to suggest any other people on here that i could listen to and also learn about the subject of SM. Thanks
-