h a l f b a k e r y
My hatstand runneth over
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
or get an account
Its tedious and superfluous to have to say See link or words
to that effect when an annotation is placed and a link is also
placed. They appear in disconnected places, and theres no
apparent relationship at all between why theres a particular
link up here and what may be being said down
As a shorthand for see link or equivalent, may I suggest the
tilde character ~ be used to signify the presence of a link
from that person related to that annotation. Which link is still
going to be a bit of a mystery, but the fact that there is a link
at all is indicated, without having to embarrassingly type out
the words see link or something so primitive.
If it catches on here on the hb, lets see where else it
migrates to out there!
||But the tilde character already has a defined meaning - it means 'approximately'
||Only when it is surrounded by context. Out on its own
it wont. I was wondering if it should be in square
brackets or something like that, but that may
interfere with markup or bbcode elsewhere.
||Most websites allow you to embed links in the middle of
your text, so I don't think this is necessary on other sites.
||My PhD was on how best to represent links in text
||I dont want to type out a bolted-on passage of text
like see link or see the link Ive just posted, all
the way up there or suchlike. Its ridiculous. If a link
is posted, it should be sufficient to leave it like that
and not even mention it, it should be apparent that
theres a link, and it is relevant to something said
down there. But its not. If I refrain from mentioning
the link, it gets missed, so I have to mention it,
which is kind of extra to what Im saying in the
annotation. So, I thought Id accommodate a simple
symbol as a kind of tag, which is still a lot of extra
work, but doesnt pollute the actual written message
quite so much with other similar things (i.e. words)
that arent the message.
||Tilde is wiggly, and therefore seems like something
that isnt part of the straight line of consumption.
||There is a unicode 'link' symbol. Not that the halfbakery supports unicode.
||If tilde already has a meaning, how about using the section symbol? You could refer to the third link posted as §3. Only problem is unless you're on an azerty keyboard the only way to type it is alt+0167 which is probably more effort than 'see link'.
||Excellent idea. The § symbol has its own key - to the
left of number 1 on the number row. Or, it is also
||The main objection is not having to type it all out
(thats the second from main objection). The main
thing is a semantic one. I didnt at any point in time
intend to publish a message that amounts to see the
link Ive just posted just before, which is somewhere
over there. All of that sort of thing, or the short-
form version of see link is not the message, and
shouldnt really be in the message. Therefore Im
compromising by slipping in a non-message /
non-meaningful (in that context) symbol.
||[Ian], it wouldn't be rendered but now you've told us all you
may as well do it anyway because we'll know what you
||Maybe something in kanji.
||It is pronounced chao1 lian2 in Mandarin, meaning
||//If I refrain from mentioning the link, it gets missed//
I have the same general feeling, Ian, & often add an anno about a link. But is it, in fact, the case? Do we have any evidence to substantiate this assertion? Or is it just our own insecurity causing us to shout louder because we think that we haven't been noticed when, actually, we have been noticed and it's just that nobody has mentioned it?
||Sorry, what were you saying?
||/ My PhD was on how best to represent links in text /
||And the winner was... blue font?
||Yes, but what *shade* of blue?
||Hooloovoo. The hyperintelligent shade, of course.
||There's this strangely satisfying compromise between raw
and formatted text called "Markdown". I've started writing
almost all/any source documentation I have to write in it
and using tools to pipe to html, pdf, word documents or
whatever. Markdown uses the convention [a link]
(http://www.alink.com) to establish links, and is quite
readable either in raw, or after being marked-up.
||I'm pro the design choice of enabling markdown in most
websites as it provides helpful typesetting functionality
without going over the top.
||I use Asciidoc all the time these days, but markdown is
related (theyre both lightweight markup languages, but
markdown is watered-down in relation to asciidoc, and
unlike asciidoc markdown comes in too many different
versions). Nevertheless, the way that both asciidoc and
markdown present links is not the way Id have thought up,
and consequently I keep forgetting the exact way round it
is. The idea of lightweight markup languages is that the
original text should be readable (and indeed editable) as
the textual message that it is, and the markup should not
prevent the message from being clear. Contrast this with
xml, where all you see is pointy brackets and duplications
of element names all over the place, the content is
secondary, buried, much more difficult to read compared
to the unmarked-up raw content. Lightweight markup
languages should try and resemble unmarked-up raw
content as far as possible. Where they fall down on this is
in complex out-of-flow things like images and links the
way of expressing those isnt how youd type it naturally,
its more complex (html embeds it in a specialised
container - markdown and asciidoc have fallen into the
||The reason I suggested this idea is that with the halfbakery
in its present turn-of-the-century design, and with the old
desktop and laptop computer being things of the past
(many people dont even own one, instead only using their
tablets or big phones for everything internet related) the
split between separating out all the links to a pile of them
in the top left of the page under the idea is ridiculous it
doesnt work as a design now. If one were to take this
thinking further, why not separate out all the dates
presented by each user name, under each annotation, and
pile those up together under the links, so that you get an
increasing list of dates that annotations were made on,
spatially disconnected from the annotation or username. In
fact, just have a separate list of usernames featured in the
annotations too, all piled up in the top left under the idea,
the pile of links, and the pile of dates that activity
occurred on. That way youd keep the usernames and dates
out of the flow of annotations and put them all away neat
||Also, for your own ideas each annotation has a [delete]
link. Dont have those scattered around embedded after
each annotation, instead have a dissociated pile of [delete]
links up there in the top left, after the separate pile of
usernames, and the separate pile of annotation dates, and
the separate pile of contributed links, and of course the
idea body itself.
||In fact, the idea body itself is fairly superfluous the title
alone usually does the job for me, and is quicker to read.
Get rid of the idea body, to make room for all those
separated out piles of stuff in the top left.
||That way, the stuff in the top left can be made just the
stuff at the top. There wont need to be this complex
nesting of boxes to create a left and a right (which itself
is divided into a left and a right). All youd have is a
single-width galley, which would make the text a lot more
readable. Then because the annotations keep growing
downward and the links and dates and usernames all sit up
the top making it necessary to swipe down too much, each
time something new might have happened, swop around
the top and the bottom, so that the annotations come first,
but still in temporal order of older to the top and newer to
the bottom (ie newer is nearer you, older is farther away
from you) and beneath all that is the pile of links, the pile
of dates, the pile of usernames, and last of all, the idea
(which changes the least, and therefore shouldnt penalise
the user by requiring swiping down and down and down and
down and down each time, as theyve already read it
||[Ian] Have you considered you are unique and need a script for your particular needs.
||No, Im not. People dont use computers these days. Most
people use an iPad, or some android equivalent, and when
theyre out, they use a phone. Always. It is very rare for
people to use an actual computer like a laptop, and rarer
for people to use a desktop. The exceptions to this are
when a person creates something (graphics, animation,
music, programming, etc) for which many will still revert
to a computer to do it. Im told that gamers still use
computers, but gaming is a waste of time, so those people
dont count at all. However, most people simply consume
rather than create, and those people have largely moved
over to tablets at home and phones out and about, for
||Gaming is obviously a much bigger time-waster than
||The people who only consume and do not create are not the
audience of this website.
||Im among a minority who uses their iOS devices to create
(in my case, electronic music, and also to a lesser quantity,
graphics). Some people even try to program using iOS, but I
find this too difficult to bother. Many of us who use
synthesisers and audio production apps on our iPads and
phones are extremely aware that although they are
allegedly a pro platform (my iPad is an iPad Pro the big
one, from a few years ago) it simply isnt treated as pro
enough. Itd be nice to be a professional designer,
developer, artist or musician and use nothing but an iPad or
iPhone (more helpfully, perhaps several) and never resort
to a desktop
or laptop computer at all.
||Im almost there, but I still fire
up the Mac Mini (one of them) now and then to do
something or other. I dont spend a lot of time on it,
though, almost all of the time in front of a screen is in
front of an iPad (and more recently my first ever iPhone
(goodbye Android, with your 0.1% penetration of the latest
Android version, and most people running an out of date
who knows what version of Android which will never ever
be updated again because the device is more than 18
months old and the manufacturer has lost interest in you)).
||The mobile-first offline-first approach is a response to the
reality that most people transact, consume and even (if
they can) create on a mobile platform. This means no
relying on a mouse or trackpad, no relying on scroll bars,
no relying on contextual menus, tooltips, no hover state,
and assuming everything is controlled primarily with touch.
Thats the reality, now.
||Of course, if the halfbakery were to take a novel never-
before-to-be-happened-hitherto approach, how about
with tipping the phone or tablet back (the top or far edge
being tipped temporarily to be lower than the near or
bottom edge as it is held) then the whole page could fall
back to the top (although this might be captured by the OS
UI layer first to flip the screen temporarily upside down
instead thatd have to be firtled around with first to see
how it can still work).