Heavy note taker here. If I'm on my Mac, I use the Notes app. My favorite things about the app are real time sync between the desktop and phone app, easy checklists, text format options and the ability to inline embed images.
When I'm on my phone I use Google Keep. What I love about it are the colored background, tile view and checklists. I wish Keep allowed inline embedding of images.
We use Google Keep for syncing our grocery shopping. It works very well, even offline (sometimes stores don't have strength for mobile data and allow you to use their WiFi but I prefer not). However, Google Keep has no API. You're forced to use the Google apps or use a browser. I also cannot get it work on my smartwatch.
Autobiography of a guy who won an auction to have lunch with Warren Buffett for $600k and ended up becoming a successful, contrarian value investor. Fun read for contrarians out there.
2) Napoleon's Buttons by Penny Le Couteur, Jay Burreson
A look at world culture and historical events through the lens of chemistry.
3) Becoming Leonardo: An Exploded View of the Life of Leonardo da Vinci by Mike Lankford
In large enterprises links to internal apps die all the time, so by emailing the actual app the end user still has a good chance that they can see what they did in a year or two from that date. Not very useful for small companies, but in large companies where you auditing is important as you often have to know what happened two years ago then this can be very useful
Tao (@taot) and I have built a tool that allows users to create screen recordings (via a chrome extension) for bug reports. I've been in the software industry more than a decade and a significant part of it has been dealing with bug reports -- writing reports and fixing bugs. Over time I've learnt that good bug reports are tedious to create, they require great detail on the steps to reproduce. In the last couple years through some projects I picked up building video tools and figured that screen recording might help alleviate that longstanding painpoint of mine -- creating good bug reports in the fastest way possible.
Having talked to users, we found that a lot of people are already using various offline screen recording tools like Quicktime, but they still require users to find a platform to upload the video to and lack collaboration features. Outclip aims to streamline the entire bug reporting process - from creation to submission, while allowing users to collaborate with each other. Hope you give it a try and find it useful. We look forward to your comments and feedback for improvement.
More broadly, reverse engineering a codebase is a critical software activity. If you can't reverse engineer a codebase you can't debug it or add to it. Working with an existing code base is pretty much a given, unless you're developer #1 on a startup. Your success as a software developer hinges on how well you can work with an existing codebase.
One less celebrated but very valuable approach to grasp a codebase is the way you document what you've learnt. While you can learn about a codebase through exploratory debugging (mentioned by someone on a separate comment) you have to persist that knowledge on "paper" in some way. My favorite ways to do that:
- class diagrams (for static stuff like data structures, class relationships, etc.)
- sequence diagrams (for dynamic stuff like which functions call which and data passed between them)
With good documentation for your own learning purposes, it'll become easier to start working on a codebase and especially when you context switch, it'll help you return to a codebase more easily.
Ideally, documentation would be written so that there is no need to reverse engineer every project you wade into. Otherwise why share the source code in the first place?
There's various kinds of documentation of differing granularity. Typically the high level documentation (coarse grained if you will) about architecture, requirements, etc. stays good over time but finer grain documentation (the kind I mentioned in my earlier comment -- data structures, order of function invocation, etc.) gets stale quickly because source code is constantly changing -- it gets refactored, plenty of bug fixes are put in, etc.
Reverse engineering is probably a loaded word, but in general digging in to understand the codebase helps you work more efficiently and avoid introducing bugs to the extent possible.
Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9% of that is only necessary after signing up and signing in, not while unfortunately viewing the page on a less-than-flagship mobile device and metered data plan?
Welcome to web in 201x. This is not a problem exclusive to Vue.
With that said, the new vue-cli uses Webpack 4 now which can do code splitting, and you can code split on route also to make individual page bundles smaller.
It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript.
If JavaScript is disabled I just show a message saying the site needs it.
I also only support modern browsers and haven't had a complaint for 3 years.
About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no complaints. This one is more "brave" but I use Modernizer and show a clear message outlining all the required features the user's browser doesn't support and why they would want that feature in a browser. There's a link to a website to help them find a modern browser on their platform.
Edit: I realised that based on what I said you could argue that users are annoyed but I'm just not aware. I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see. The last time this had to do with browser support was one message 3 years ago about IE9 not supporting the TLS certificate or something. They were forced to use IE9 at work.
Without hard data, this is pretty meaningless. If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint.
> I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see.
Maybe existing users (and even for that, I'm skeptical), but how many potential users did you lose because they couldn't even open your app?
I'm not saying you are wrong, just that "users didn't complain" != "users weren't affected".
>If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint.
And I wouldn't miss you.
I can make the service better faster if I don't support the lowest common denominator. I'm sure I'd lose more users if the website was bloated with fallback code and my development speed was such that features are a year behind where they are now.
The time you spend dealing with old browsers is never returned in profit. I had one customer (ie10) in 4 years, and losing him cost me and made me nothing.
But dropping support for certain browsers/clients without having data on how many of your customers would be affected is silly, IMO. You might decide to drop support for IE 11 because you want to use CSS Grid without hassle, but then it turns out that 10% of your users use that browser! As with everything, you have to weigh the tradeoff, but you can't do that if you don't have the data to begin with.
Sorry, you are correct, I made that assumption. It seemed implied by your use of user complaints as a metric of success—I assumed that was the case because you didn't have hard data, so I apologize if that's not the case.
Not a problem at all. I place high value on being available to users of my website. I reply to each and every message. Perhaps it's a bit unusual for someone to talk about that before the numbers.
It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers.
But, as a little Latina girl once said, why not both?
I think the other person was talking about quantitative data (e.g. from Google Analytics), not qualitative data from customer conversations / complaints.
That's a really good point, and it's one of the drawbacks of designing a website for the 95%.
I haven't tested myself (I'm just one dude - there's a lot I'd like to do but haven't yet), but I see no reason why it wouldn't work well. I try to design semantically and everything is rendered server-side.
But, in reality, I don't think this is the kind of website that would be usable for a blind person anyway. There's not really anything to read. There would be much better ways for a blind person to get information than using this website.
Vision impairment is a spectrum, so someone who can see to some extent may be using a screen reader to assist. People might be using your site at 150% zoom, etc etc.
One thing you can do is put a note somewhere easy to find that says "if you require assistance using this site, email someone@domain.org". Sites that I've worked on also had a phone number here but I understand that's an edge case.
You also mentioned alternative ways to get information - if there's ones you can link to (without linking to a competitor or whatever), there's no reason not to provide links.
I don't think this is the kind of website where I "help someone to use it". Instead of speaking in the abstract I may as well show you so you can see what I mean:
As you can see, the whole point of it is designed around quickly glancing at prices. And I don't think it makes sense to tell people other places they can find prices if they can't see well enough to use this website.
It's been a while since I looked at things like this but have you done simple stuff like check whether the colour contrast ratio [0] meets WCAG standards?
What about making the orange highlight work when tabbing through the website with the keyboard?
What about having a Skip Navigation / Skip to Content link? [1]
Yes I keep those things in mind while developing. I may have missed one here or there, especially in any code from my early days of development.
Thanks for the link about "skipnav" I haven't heard that term before. I don't really see how that can fit in, though? I guess the category links right at the top of the page is the closest concept?
It doesn't make sense to skip down to item number 200 since there's no way to know what's down there. Best to look at items 1-199 first. That is the same for all users.
It's exactly to skip to the main block of content - every item in the nav menu may be read out individually (or at least needs to be tabbed through) otherwise.
Oh I understand now. It's skipping the menu itself. I don't know why I misread (skimmed) the link you posted. Yeah, I can see why that's useful. I'll add it to my to-do list to look more into that. Thanks!
I find their recommendation skipnav somewhat ironic - pages on that site with any sizable contents don't show any actual content until after the fold on my macbook, e.g. https://webaim.org/techniques/css/invisiblecontent/ .. the entire first page consists of various forms of navigation.
Edit: using a screenreader effectively is a skill in itself. There are consultancies around accessibility testing. I am not affiliated with any of them.
Well for what is worth, I had been thinking on the idea for a while after growing tired of so many scripting and tracking everywhere, and I felt encouraged to make the jump and disable Javascript after reading this comment in HN (thanks bmurphy!):
> The single best improvement I've made to my mobile browsing experience in years wasn't getting a new faster phone, it was installing Brave and disabling javascript. [1]
To be honest, (s)he was right. But at the same time, it's disgusting, and plainly bad, to see how much of the Internet is _broken_. Which by my definition means requiring JS even to show some text and images on a web page.
I understand that more advanced features might require some scripting, but come on, I'm pretty sure that's not the case for printing some good old letters and pixels on a browser window! And still, lots of places seem to not know how to do it without dynamic code all around. (I'm not talking about this specific site, in any case. Just felt like ranting.)
I usually leave it enabled, I just tested it when I viewed the page source and saw very little was there beyond JS. I guess I come from a different time where you used as little JS as possible/was required.
I'm also not familiar with vue so I was trying to work out if it was used to build your web page or the actual chrome app. The web page is fine but I just wasn't sure where vue came into the picture for such a simple site.
I like this point in particular -- "Don't stress out too much about how valuable the things you're going deep on are." The general stance of people is to stick to the practical stuff -- knowledge or skills that you can use right away. But, it's important to have a long view and given enough time the impractical could turn into something practical. Serendipity is underrated, and in my experience the impractical stuff is what enables serendipity.
When I'm on my phone I use Google Keep. What I love about it are the colored background, tile view and checklists. I wish Keep allowed inline embedding of images.