Also called Ell Dee

"dike  -  noun: an embankment for holding back the waters of the sea or a river." Applicable third-person pronouns: she (singular), ey (s.), they (s. or plural), and other neutral ones.

[lohauserdike]

More ways in which tumblr is bad

Aside the other difficulties, also found out "the hard way" that once an entry has been saved while marked answerable by checking the option labelled "Let people answer this" (which by the way pops up only if the entry's text ends in a question mark), there doesn't seem to be a way to edit the entry to uncheck the option. (The check box can be unchecked if the entry's text is modified, but upon saving the entry then, the entry will actually stay answerable.) Didn't find any workaround short of deleting the entry and re-creating an entry with the same contents (which will be marked with a later datetime).

And something else, editing one's entries on the dashboard seems to become increasingly more laggy the more content there is, to an almost unusable degree already.

[lohauserdike]

Depicting how the current theme mod renders the datetimes and amounts of notes.

[lohauserdike]

Finished third iteration of the theme.

Removed the height that was originally defined (and once adjusted) in pixels for the part with the datetime and amount of notes; positioning parts of the layout by specifying distances in pixels doesn't seem an all too good design anyhow. That seems to make the bar resize to fit around the text as intended.

Right-aligned the text of the "numerics" lines (Unix time number and amount of notes).

Put the amount of notes into its own line so that it has enough space despite the two longer-than-default datetime stamps.

Specified a monospaced font for the amount of notes, too.

Some source text normalisation to improve semantics/styling separation. (Not using the HTML font element; instead, div elements are used with classes and the classes are then styled in the stylesheet.)

Don't even know what the point is of documenting it like that here. Certainly the proper source history belongs in a DSCM repo eventually... sharing of that is going to be complicated though, refer to Tumblr's Terms of Service, Section 9 "Blog Themes" (Line 217) at revision 3abbdd13fd, current as of 2013-10-13T23:50Z, and specifically how it limits distribution, the lack of details on whether modification of the themes is even allowed, let alone the apparent failure to provide the so-called "free" themes under software-libre conditions.

And yes, incidentally, that is one of the ways in which tumblr is bad. And certainly something that, despite their assurances that it's only to "manage the safety and stability of blog themes" (Community Guidelines), is done in a way so that it furthers lock-in of users and content, and implements the lock-in even of mere implementations of the aesthetics. (The latter is most gratuitous because that isn't exactly part of Tumblr's business model.)

Like both of these documents mention, there's the "Theme Garden", with the Community Guidelines stressing that "anyone can host and promote their themes", but it seems that the one submission form doesn't actually publish a theme but rather submits it for Tumblr staff approval. That could arguably be fine on its own, but not with how intransparent the entire process is. No, strike that, it's a walled garden one way or another. Don't like it.

Even ignoring all that, the technical side of theming is either fairly limited or only seems so due to how badly it is documented. Eg, #timezones anyone?

Sigh. This tangent is long enough already.

[lohauserdike]

The first reblog incidentally exposed a bug in the theme mods. Might just make that bar contain three lines, though that would make it even blockier. And now how to make it so that only affected entries contain the third line?

[tarintowers]

I’m not sure how to describe this link other than flash fiction disguised as a bug report, unless it’s a bug report disguised as flash fiction.

[lohauserdike]

(Explaining this reblog to the future readers of this blog:) Found this while randomly browsing tags for an upcoming text... Though very unrelated to that, did enjoy the read. Have both a love for anything time travel and an appreciation of writing in many of its unconventional forms, after all.

[lohauserdike]

Keeping the Unix time numbers just in case tumblr should mess up timezones again, though.

[lohauserdike]

Timezone setting that presumably uses +00:00 permanently

Found after the earlier review that, apparently, out of the two "GMT" settings, there's one with some sort of seasonal timezone changes (labelled "(GMT) Greenwich Mean Time : Dublin, Edinburgh, London", internally selecting "Europe/Dublin") and another that apparently doesn't have any of those (labelled "(GMT) Casablanca, Monrovia", internally selecting "Africa/Casablanca"). Speculatively then, all the datetimes formatted (in ISO 8601) on this blog, which were previously marked as "local", will now stay as UTC permanently. Hence they will now be marked with the 'Z' (as in ISO 8601) to indicate this.

[lohauserdike]

That self-selected suspension of tumblr usage endured for a much shorter duration than usual.

[lohauserdike]

Seems that timezone handling is not all bad actually.

It's only that datetime stamps in all entries appear to be controlled by that one "Timezone" setting on www.tumblr.com/blog/NAME/settings which unfortunately doesn't clearly indicate whether and in what way seasonal timezone changes (incl. "daylight saving time", "summer time") are handled. The datetime stamps on the most recent entries imply that the selected "GMT" setting actually uses +01:00 currently, not +00:00 (ie UTC). Need further testing to find out whether the current effective timezone trivially determines the offset used with all datetime stamps, or whether seasonal change rules of the selected timezone are applied in a proleptic manner so that datetime stamps of specific entries are constant across the year while the same selected setting is constant (entries would then have local times of different effective timezones depending on when they were published). Don't know which is the worse. However, seasonal timezone changes along with unmarked local datetimes are clearly at the root of this; unsurprisingly, both are bad. There does not appear to clearly be any UTC setting that doesn't use any seasonal timezone changes. The tentative examination of the themes mechanism yielded no way to mark local datetimes with their effective timezone. Presumably, no information is stored on the timezone used by the author of an entry while submitting it. All right, there is not a lot of timezone handling that could be worse, apart from permanent corruption of the metadata. Not particularly happy with it being severely inaccessible, though.

[lohauserdike]

Another attempt

[lohauserdike]

An educated guess: Timezone handling is completely beyond hope, too.

[lohauserdike]

Not even tags are parsed in a sensible way by the email reception. And what is it with the order of tags? (Theme-related?)

_is_bad is bad

[lohauserdike]

Turns out that HTML source text doesn't seem a complete workaround due to the Markdown indicator code. Oh well.

In other news, the plain text reception apparently deleted the URL included with the previous entry somehow. Furthermore, the way this user agent wrapped the plain text email apparently caused the plain text reception to insert br elements after each linebreak as it occurred in the email. And then the Markdown source text reception apparently deletes tags and also some text that is Markdown-formatted in some specific ways. Didn't expect their handling to be /that/ bad. To mention, presumably there is no way to queue the entries published using the email interface. All in all, given this start, again the phenomenon can be observed that any tumblr usage causes the urge to write, host, and use an alternative to rise, permanently and steadily. This is not a good thing. And then the situation around theme development, available themes, and the bad conditions of both the former. And the all too conventional lock-in of content and users. Only the most essential considerations. Seemingly, tumblr is still exactly as hostile on the technicalities and usability as remembered from former experiences and first impressions. -is-bad -copyrights-unquote

[lohauserdike]

Test entry, ignore

Test Test

[lohauserdike]

Test entry, ignore

Test Test

[lohauserdike]

Test entry, ignore

Test Test Test Test Test

Test

[lohauserdike]

There seem to be some scary heuristics in effect which will determine what type of entry the user presumably intended to submit, based on various aspects of the email's content. Some of this is documented on but it isn't documented that there are a full three categories of text posts, as follows: * (documented/implied) plain text emails * (documented) Markdown-formatted emails * (undocumented) HTML-formatted emails There is a special "code" in order to indicate Markdown formatting, although this is problematic because the code is supposedly detected "in any part of the email's subject or body", therefore (for instance) this entry cannot include that code lest it will be a false positive. Note that the HTML to plain text distinction applies not only depending on the type of the received email; in all tests as yet only emails containing plain text were sent. That is, even for plain text emails, tumblr's receiver uses some heuristic to determine whether to read the text contents (of an email determined to be intended as a text entry) as HTML source text or as plain text, with all that implies on its own. Furthermore, as for the documented Markdown indicator code, it might be that any text in the entry that reads like HTML mark-up might be misinterpreted as the user's intention to have the text interpreted as HTML source text when this wasn't the case. Aside all of that, it is unclear what precedences apply particularly to the determination of the email as HTML instead of Markdown source text. This knowledge might be necessary to implement a workable alternative. (The latter must allow the user to know how the email is interpreted without having to check after reception by tumblr, and ideally would allow entering any text to appear literally in the published entry. The second requirement already rules out plain text for this.) If detection as HTML source text has precedence over detection of the Markdown indicator then sending easily-detectable HTML source text should be a sufficient workaround. The right way to do this would be to have explicit ways to indicate to tumblr's receiver how to interpret the email's content instead of the unwell-documented heuristics. (The lack of supplied documentation and lack of details in the supplied documentation worsens the usability, but the design approach of heuristics is arguably fundamentally wrong for advanced use cases.) It is clear why the heuristics design was chosen for such a feature, but there should rather be alternatives with the heuristics in place as default only rather than a requirement. As a requirement, it turns the feature into somewhat of a mis-feature, by making it a hassle to use it for some use cases. Furthermore, the entire feature of publishing via emails should be configurable to be enabled either only from select email addresses or from any email addresses at least. Optionally requiring further authentication would be even better.