@gnowgi is always encouraging us (rightfully) to post on Stemgames where our posts can be seen and commented upon by everyone instead of posting on just Telegram with its much more limited audience and a lack of accessible archive of posts. So that got me thinking, why we do what we do. Either Stemgames is more difficult or Telegram is easier (or both) leading to more friction posting on Stemgames and less friction here. This could easily make for a scientific experiment whose results we could post onā¦ ahemā¦ onā¦ github (?). So, here goes ā
posting on telegram (all actions starting from zero)
click on Telegram icon
click on Glab group icon
type
hit enter
posting on Stemgames
click on Safari
type stem (Safari fills in the rest)
2a. close that big yellow banner that pops up everytime encouraging me to download the app but somehow forgets that I closed it the last time and donāt want it back
click on big blue + sign
type a topic heading (this could be the biggest hurdle)
choose a category
select and delete that encouraging but useless text about what kind of activity to post today
type something (took me 7 steps to reach Telegramās 3rd step)
hit done and then be scolded that the title must be atleast 15 chars and the post must be at least 20 chars
(grumble)
change the title and the post (big hurdles)
click done
Friction in software design must be one of the most overlooked characteristics. There is some reason a billion people can use WhatsApp without any training but canāt use a banking app (even for just checking on their balance).
By the way, I clicked ācancelā on my initial test post on Stemgames instead of actually posting it, I was prompted whether I wanted to abandon it or not. The motive is to help, but becomes overbearing in use.
And, the process gets even more complicated if I want to post images. With Telegram, I just drag a photo from my Photos app onto the Telegram app and done! Telegram even auto-resizes the photo so it is small and not full res which is just a waste of bandwidth. With Stemgames, I have to go through a bunch of shenanigans before the images goes up. And all 3200 pixels of it, even though almost everyone will only see it in 800 or 960 px width.
There have been several (more serious) studies about the impedance afforded by having to think up of a title for a document before typing what we want to type. Case in point, the legion of āuntitled.docā, āuntitled-1.docā, āuntitled-2.docā littering our hard disks. After all, when we write on a piece of paper, we donāt have to first write a title. The act of thinking of a title is such a big cognitive commitment that we just give up or bypass it.
So, the invention of digital notebooks (such as Microsoft One Note and Apple Notes app) which donāt ask for a title ā they just make one up for you. Unfortunately, they have to usually then store these notes in a database and not in files, because the filesystem requires a title name. Thinking up of a name for a file is just as difficult if not more so than thinking up of a title because of the restrictions imposed by the OS. We win some, we lose some.
Ok. This one from my new phone browser. Firefox. Firstly requires cookies. FF on mobile does not allow cookies only for some sites. It is all or none. A wholly untenable situation. I enabled cookies and logged in. I will now disable cookies.
yes, of course! that is a yet-another layer of the problem. And making an HTML-JavaScript app and pretending it is a native app doesnāt cut it except for a very limited set of use-cases.
yes, most apps, even the most benign ones, use/require cookies. I am making a web app right now which doesnāt use any cookies or any kind of tracking whatsoever. But that is a very rare breed. There is this app (on the Mac) called Fluidapp that converts a website into a standalone app. There is a similar app for iOS. You might want to search for one for your phone OS. Such an app would let you create a site-specific āappā so you can use Stemgames with cookies and other websites without cookies.
The developer team could list out critical reasons why a) this is a psuedo-app nested inside a browser, working only with cookies and b) what hurdles face the team that is delaying the creation of apps for Android and iOS.
Throwing this open to the larger group of participitants using this service might bring in fresh ideas and also whatever assistance is needed to fulfill them.
I am delighted that this discussion is happening on STEMGames and not in ##Telegram chat which is not archived archived on the web. Another significance of this post is to systematically present after analysing the case, so that those who respond to this also follow that ##STEMHabit.
Most of the concerns are justified, and these concerns can be met only if we have an app that behaves differently from the default behaviour of Discourse. This requires development resources (developerās time). I am confident this day will come soon.
I would hesitate to remove the constraints on 1. need to provide a title of at least < a limited number of characters >, and 2. size of the message. We can only argue about reducing/incrasing the size, and not the rule itself. These are essential for posting an academic micro-blog that initiates a discussion. If this is inconvenient, then it will be inconvenient to bother a community with a post that cannot be given a title. Please consider this as ##rules of the ##STEMGames. This way we are also encouraging contributors to curate their posts, so that the visitors can retrieve posts based on the ##metadata.
All other points are valid, and must be resolved as soon as possible.
I also want to add another dimension to the rule based practices: We recently had a Telegram based conversation that went on for over a week, which made some members leave the group, since the so called conversation created at best a cacophony (for want of a better term), and also the discussions went orthogonal, because the participants were posting at a very fast pace, and with little restraint. This lead to a very long thread, but eventually rested without any fruitful result. But had a negative result of a member leaving the group.
These things can be reduced in a forum created for civilised discourse, since the participants may not want to go personal in a public space, and if they do, we can flag such posts.
Also, quoting a part of the message is very important in a threaded discussion, which is not possible in Telegram/WhatsApp.
Ease of use cannot be always considered a virtue, but must attempt to minimise the effort to develop restraint while communicating in a public space.
That makes sense. So, the important take-away is, Stemgames is a rules based academic-ish discussion site. If we keep that in mind, it adds value and is worth stewarding. (back to this in a bit)
It slows down the response rate. That can be seen as a virtue because it ensures more thoughtful responses.
Since I am a believer in the basic formational principles of the web, I whole-heartedly agree that bookmarkability, URLs, and archival are virtues, and Stemgames fully shines on these aspects.
I do disagree that āEase of use cannot be always considered a virtueā. I would say that ease of use should always be considered a virtue because, like a thoughtful response, ease of use takes a long time and a lot of work to develop.
Yea, I can live with the size limits on the title and the message body because they slow me down. And, Iāve already agreed that slowing me down is good Of course, that doesnāt change the fact that thinking of a title is a pretty big cognitive load. But, so be it.
By the way, Stackoverflow is mostly based on Discourse. Or rather, vice versa. Discourse is based on many of the Stackoverflow design principles and practice. SO, of course, is one of the best discussion sites even though it shares with Discourse some of the sources of irritation mentioned above. SO has gone through a lot of polishing. Similarly, I believe Discourse will need a lot of customization and polishing to make it work the way one wants it. That would be a goal worthy of our time.
We shall take up this challenge this summer, with a couple of interns joining us, it seems feasible. The main idea is to use the Discourse API, and build a mobile first UI, as a progressive web application.
Apart from usability due to cell phones being the preferred hardware platform, there seems to be a āfearā of posting on stemgames. Is this because of the fear of being seen as raw in the eyes of superiors?
IMVVHO every one of the discussions on telegram can easily be posted here.
āIsnāt cooky accept policy site-wide? Why would other tabs get affected?ā
Not on android. FF has no setting for accepting or rejecting individual websites.
In my view there seems to be multiple factors at work:
Hardware restrictions - >4GB ram
Net availability in the case of workshop participants
Convenience and familiarity with existing software apps
Non availability of native discourse app
Fear factor.
Personally I find instant messaging and phone typing to be extremely painful and prefer the desktop and browser. The present user interface of stemgames on desktop seems quite ok to me.
But nowadays, with swiping as an available option on Android, at least, my opinion has changed. Although thatās probably because Iām still such an amateur typist after decades of using keyboards.
So hereās the thing: swiping is the closest analogy to handwriting since the advent of keyboard based computer access. Someday, some hardware designer will notice, and then it will become the easy way to write to the desktop.
For the present, though, it is a strong argument for accessing STEMgames via the phone.
I assume the mention of Discourse and StackOverflow was pertinent to the manner in which STEMgames is implemented. Iām afraid the references just flew (overflew? ) over my head. I have not understood why this āappā is not an āappā, and appears/behaves like a fairly curious microbrowser.
Our request was heard. Four interns of BITS Pilani took up this challenge. Please guide them for a clean, simple, get things done kind of client for metaStudio.org.
Now time to discuss UI and UX details. @punkish Do you want to join as a mentor for the interns?
I will be happy to mentor, provided (and I summarize below the points I raised on Telegram):
There has to be someone local to interact with the interns on a daily basis. I can mentor them (as well as the local mentor), via Skype calls perhaps once or twice a week to check-in. But with the time difference, it is hard to coordinate conveniently. (Plus, I have my my own projects to focus on.)
Re. recommendations on frameworks, I actually do not use any JS framework unless it is for very specialized functionality such as mapping or charting.
I also do not use any interface/CSS framework anymore. But I used to like Skeleton very much because, well, its name tells you all. Then I moved to Barebones because, well, you can again guessed from the name. Barebones is an evolution of Skeleton, and uses CSS Grid, which is useful to learn and highly modern.
I must warn upfront that I am obsessed with speed over functionality and certainly over looks. I prefer minimal and fast. I consider speed to be a feature of design (just as much as looks would be). So all my mentoring will be funneled through that lens.
If you all desperately need/want a framework anyway, perhaps Vuejs might be good. Iāve heard good things about itā¦ just to clarify, I have never used it, so I wonāt be able to help with Vuejs-specifics. And now with ES6, a lot of things are simplified obviating the use of frameworks. So, I would recommend starting with vanilla ES6. Since you will be using an existing API, most of the work should be REST queries via fetch and filling in DOM elements.
If the above sounds good, I am happy to get involved.
Of course, that doesnāt change the fact that thinking of a title is a pretty big cognitive load. But, so be it.
) over my head. I have not understood why this āappā is not an āappā, and appears/behaves like a fairly curious microbrowser.