I personally hate using font awesome. I think it looks dated and already too generic. Every website that uses default unedited bootstrap and font awesome set looks so bland and indistinguishable to me.
OTH if you use their icons from e.g. Bootstrap as they are usually used then users actually recognize them without thinking and the icons actually help users interact with your website - which is the point of the icons anyway!
The same goes for classic simple buttons, nav bars color pallets etc - users know them already before they interact with your site. Most of that design work you did to make you site "different" or "beautiful" just made your site less intuitive for a user.
This opinion comes from experience building b2b webapps - users generally wish they didn't need to do the admin work the webapp is helping them do. So user stories are dominated by building the simplest quickest workflows to allow users to capture, fetch or manipulate the data they need and to then get back on with their lives - having standard controls that are familiar from other sites helps with this.
Vas majority of the websites that use font awesome icons are cheaply made projects that fail to get traction most of the time and have a relatively small user base. So using font awesome icons with an idea that it will help users recognize what they represent, is flawed. I doubt regular users who according to you "would have trouble figuring out what the icon means if they did not see it before" even visit the type of sites that use font awesome icons, they are primerely used by small startups or one men shops with users mostly coming from sites like HN or producthunt anyway.
You can include the <svg> directly in HTML source code. No extra requests needed. In some circumstances it might be a better trade-off. Especially when you use a small amount of icons.
Also, you can style each path individually using CSS or SVG. That means you can easily have multi-color icons.
I know I at least am getting skeptical and a bit unsure of the licensing guidelines of font awesome. A fully-MIT product might be a bit reassuring for some people. Font Awesome seems to be more transitioning to wanting everyone to pay for licenses (yes, there's a free model, but they're pushing pro pretty hard)
Can someone more well-versed in Indian law help me understand : Does this ruling prevent collection of biometrics or restrict it somehow under the Aadhar system?
Also, I recall the Indian Government was pushing Aadhar Pay - a biometric fingerprint scan based PoS payment / verification system (likely it is already deployed, I don't live there so I don't know). What happens to that now?
When the Government of India (GoI) mandated Aadhar for provision of many services (subsidies, marriage certificates, death certificates, collect taxes- people without aadhar can no longer pay income tax - etc) it was challenged legally in the courts. One of the main arguments was that Indian citizens had a fundamental right to privacy, and such 'enforced' collection of biometrics violated that right.
The Attorney General (appearing for the government) argued that there was no such fundamental right, and that citizens had no right to privacy.
This (whether or not privacy is a fundamental right) had to be resolved before these cases could move forward.
So the question was 'forwarded' to a 9 judge 'constitutional bench' to rule upon. Today all 9 judges ruled that Indian citizens had a fundamental right to privacy.
so now the Aadhar specific cases can go forward, now that there is a 'constitutional bench' ruling. A 5 judge bench will now consider those cases and rule upon the legality of Aadhar enforcement.
This ruling, that privacy is a fundamental right, will obviously affect the outcome of the Aadhar specific case(s) but how exactly - including what restrictions if any, could be placed on biometric collection via aadhar - is not known (yet).
That is my non lawyerly understanding of where things stand.
So, basically, this has opened the door to debate about the legality of collecting biometrics, but we still have to wait for official rulings to see if a stop is put to collecting that data under the Aadhar umbrella?
This is a 'high level' ruling, which unlocks the 'deadlock' on the cases about the legality (or otherwise) of biometric collection via Aadhar for specific government schemes.
The Attorney General's argument that citizens have no fundamental right to privacy has been invalidated/overruled/whatever-the-correct-legal-term-is, by the constitutional bench. He (and his team) have to find new arguments now. [1]
The lawyers of both sides on those cases, now have to proceed on the assumption that privacy is a fundamental right. The pro-govt (so pro -aadhar) side will likely argue for 'reasonable restrictions' on the right. The anti govt side will likely argue that such restrictions are not 'reasonable' and that aadhar violates fundamental rights (or so my lawyer friends tell me [2]).
[1] Tangential: The AG who made that argument has retired, and there is a new AG who will appear for the government.
[2] They are probably oversimplifying, so I can get the gist, the same way I would if I had to explain some complex programming to them. I'm not a lawyer. :-)
I'm not sure many people would be interested, but I'd have no problem doing a write up with the relevant source. I'll try to get to it next week after fixing all these bugs people are finding.
How does this compare to other popular solutions? Specifically, KeepassX / Keepass2 which are the most common solutions I've seen most Unix / Linux users employ. Can we objectively state which one is a better solution?
So it does, yes. I forgot about that, since I needed to write my own wrapper to paste both username and password (stored on separate lines) anyway. Thank you for the correction, I'll update my post.
There is also QtPass (GUI around pass), and various browser extensions (e.g. BrowserPass).
Of course one has to set it up, it's not an integrated solution. But GPG provides interesting features like storing encryption keys on hardware devices. Some devices like Yubikeys can have touch-to-use enabled. So each use of a secret requires a touch (after PIN but that's once a session). Perfect combination of convenience and security for me.
Pass encrypted passwords are kept in your computer, which I find safer than web based solutions. Optionally you can use git to share passwords between computers but you still need the gpg2 keys from the original repo.
This is amazing! My burning question - as has been pointed out in the thread, the effort to produce a great article on Distill - generating interactive figures, doing front end web dev etc. would require a lot of time and resources on the part of the researchers. Is it possible to include within Distill an option to connect researchers to willing-and-able developers in those domains (for example, me) to help them get it done?
