bphogan

And what do you mean about handling dividers?

I look forward to seeing this work, but I worry about the hardware requirements that will be imposed.

I have a 2007 white macbook that zooms flawlessly. If I need a high-end video card to zoom as smoothly it will be a problem.

I use the full screen zoom and run Windows apps in virtualization. That's how important it is to me.

Ubuntu tried to make this work with Compiz a few years ago, and it was terrible as well. Slow and jerky.

But this is an absolute necessity for a low vision user like me. Got a Mac for my dad and he also can't live without it now.

But if you're on Linux and you're not using i3, gosh, you have to give it a try.

But I can say from a beginner to iOS standpoint that this looks amazing and I will put it to use in an app I am building immediately, as soon as I can figure out how.

To the author of this library, thank you.

I'm the kind of person you'd find frustrating at first. I don't want to know all the internals of what I'm doing before I dive in. I want a nice API and good docs, and I want to build some stuff right away. And if I can't do that, I give up and move on to something else.

If I like it, and it gives me quick wins, then I'll dive into the guts of how it works. Because I'm a responsible developer.

But I have learned that with all the things out there to learn and absorb, I don't have time to deep-dive a framework before choosing to use it. There's something else coming that I have to do next week that uses something I don't know.

So the more I build stuff, the faster I get at picking it up.

Provided that developers use the proper HTML tags and ARIA roles, there shouldn't be any different issues here than with other JS libraries.

However, I want to stress that React, Ember, and Angular are amazing tools for apps, but if you are using them just to render static content, you're just inviting all kinds of accessibility issues that server-side rendering solved years ago. Web servers are optimized to serve static content quickly. Sending JSON to the client so the client can render HTML for a blog post or news article seems pretty wasteful, and again, invites accessibility issues that don't need to be there.

Some personal examples:

For years I've worked with Microsoft products. The company I worked for paid big bucks for Microsoft enterprise support. Tried to use many times, always same results. "We'll send this to engineering." Never a response.

Same with Apple. Bought an iMac that repeatedly ejected USB disks. Known issue. Apple support forums have hundreds of unanswered, unresolved threads on this issue. Yet Apple support had "never heard of it." Same "we'll send your logs to engineering and get back to you." And never heard back.

Local cable companies call you constantly to get you to sign up for services. Then when there's a problem they'll come out and fix when they feel like it.

Got a problem with your Google Apps account you pay for? Good luck.

Sell something on Ebay and someone screws you over? Ebay still keeps their cut of course.

Paid $1500 for Google Glass, found out explorer project was shutting down through Twitter and The Verge, rather than Google.

Had a Digital Ocean box disappear for no reason. Response from them was "sorry." Saw a recent article where someone else had that problem too.

Had a similar issue with a Linode box. Same results.

So maybe I just have terrible luck.

But I'm willing to bet that there's way more money in sales and marketing than there is in supporting existing customers.

Forking over money to a company provides zero benefits other than the use of the product or service, in my experience. You get no say in how things work there, and you're lucky to get someone who is actually empowered to help you.

When I get feedback, especially negative, I like to think about it before I respond. And I may take a month to respond.

But I always immediately respond with something like

"Thank you for providing feedback, and thanks for your patience while I think about your feedback, discuss it, and respond appropriately."

At least you then know I'm not ignoring it.

and a log was copied to your clipboard so you could paste it in...

Number that attempt to get involved is unknown.

I require 1st semester students to push final projects to Github public repositories so they learn Git.

Biggest problem is that they can't program very well yet but want to contribute. So any low-hanging fruit is welcome, really.

Just because you pay for something doesn't change the rules. New code has to be supported. And if it's a business, you have to pay people to support that new code.

All the people making money on books about ES6 could kick in. All the folks making screencasts could kick in.

All the companies making money on open-source could kick in.

And volunteers? They should cycle out and move up into more interesting work, making room for new people to do that. That's what I was thinking.

I'm not underestimating the issues they get. I looked at it before I wrote what I wrote. It's a lot. But I'm not going to feel bad for them. They have a massively successful open source project. And only 5 people. Despite lots of use. I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution?

I'm not being lenient on Github either. Their issue tracker is incredibly limited. It always was. I remember when they launched it and they were very clear about its simple limitations. Simple is good. Until you're a massive opensource project using it as a catch-all bin for troubleshooting issues.

I find it ironic that open-source maintainers sent the same kind of ranting letter "demanding" certain features in the same "entitled" manner that their users do to them. :)

I've been in software for a long time. There's no tool that solves this problem. People who don't know your software don't know how to report issues. They don't know the keywords or nomenclature to search for pre-existing error messages either.

Switching to another tool won't solve this problem they're having. Typical engineers - they think issue templates will help. No. I'll just fill in whatever gets me past the validation cos I'm frustrated.

This might be unpopular, but you're under no obligation to answer those issues or even have a public issue tracker at all. Turn the issue tracker off if it's frustrating, and use a private issue tracker for the core team. Or find some students that want to break into open source and have them be 1st level triage for your issues. It's a people problem, not a technology problem.

Too many developers forget that software development, even open-source, is 20% code and 80% people. Documentation and support are a huge part of software. And software only goes so far to solving that in my experience.

Surely there has to be a middle ground. :)

But it's tiring and taxing, and it takes time away from interacting with the people who do want to be there.

These little quips like yours usually come from people who have never taught a diverse group of students before, and they are condescending to people who dedicate their lives to teaching others.

You pay me a nice salary and let me interact with students who want to learn and I will gladly develop great curriculum and deliver excellent results.