I don't know much about React, but I look at projects on github all the time and you nailed everything here. Demo right up front, well organized & well written docs, tests passing.
The project is still actively under development and accessiblity is something not yet fully implemented but the goal is to get there eventually very quickly. I have not advertised as fully accessible.
Can you clarify a bit more on the keyboard navigation working poorly. may be logging a issue on the repo would help me to solve it quickly.
as for problems in safari, i use a windows laptop and i haven't got the opportunity to test on safari thoroughly. But this will be looked into on high priority.
I understand the importance of accessibility (obviously) but I've see that there is a whole community whose first response to anything new is "what about..." as if its unthinkable that you would build a V0 without considering every possible special interest. I think everyone if pulled up by progress, and building something new, even if it doesnt work for everyone out of the gate is still a step in the right direction that will eventually lift everyone up. So don't worry about the "what about..." people, they want to bring everybody down
Detailed criticism is meant to bring people up, not down. There are better web communities if the only thing you want to get is encouragements (not that encouragement is bad, but it's way cheaper than criticism). It's your choice to see the critique as "this is a roadblock", or "this could be a good roadmap item".
If someone gives you a gift you think is broken, you ask them to empower you to help mend it. And if they offer to get it mended, you at least offer to go with them.
That said, yes accessibility should be prioritized.
Nothing in that list was "negative". They were all dry factual statements. Tone policing people for being "negative" when they're not is in and of itself quite a negative thing.
If you don't want to be considered a jerk, in polite company you would say something like "This is a nice project. I have a few suggestions and bugs regarding accessibility:"
I'll keep an eye on this for the responsive feature that's planned!
I recently implemented a timeline on the https://wavy.fm front page to communicate that the website is still in development. Trying to make it responsive with flexbox was an absolute nightmare, so I ended up using JS to render the component differently on mobile.
I expected `tree` to allow multiple side by side (but still synced) timelines. For instance in your examples there'd be one line for European ops, and another for Japanese. Any plans to add that?
Vertical-alternating seems very clear to me. Also consider allowing vertical-alternating to “compact“. Reducing blank space may be of value for some designs.
I've wanted something like this for a while, but it's missing what to me is the most important feature: scaling the distance between entries based on the length of time between them.
Fantastic job!
For your interest, there is a small group of hobbyist developers and small companies developing timeline products for the web.
As the developer of ChronoFlo Timeline Maker (https://www.chronoflotimeline.com), I welcome you to the timeline maker community!
Good luck with your project.
- There are no landmarks.
- The keyboard navigation works poorly.
- There are no live regions to show changing content.
- The markup is a sea of divs and spans, so there is no structure to the content.
- There is no visible focus indicator.
Some of the advanced layouts do not work at all in Safari, accessible or otherwise.
The project is still actively under development and accessiblity is something not yet fully implemented but the goal is to get there eventually very quickly. I have not advertised as fully accessible.
Can you clarify a bit more on the keyboard navigation working poorly. may be logging a issue on the repo would help me to solve it quickly.
as for problems in safari, i use a windows laptop and i haven't got the opportunity to test on safari thoroughly. But this will be looked into on high priority.
To be fair, a lot of simple stuff doesn't work on Safari. I recently noticed that Graylog's static navbar is broken on Safari, and only on Safari.
I use Safari because it offers great battery life but I don't expect it to work well everywhere, it sucks as a browser.
That said, yes accessibility should be prioritized.
"leaves a lot to be desired"
If you don't want to be considered a jerk, in polite company you would say something like "This is a nice project. I have a few suggestions and bugs regarding accessibility:"
I recently implemented a timeline on the https://wavy.fm front page to communicate that the website is still in development. Trying to make it responsive with flexbox was an absolute nightmare, so I ended up using JS to render the component differently on mobile.
Sure you can break it up with capital letters, bold but it gets boring and dull. Adding emoji's adds a bit of toybox excitement.
If they are used correctly, it can make a document more appealing. When not then it makes the page look ghastly.
Small thing: Your "Built with" links at the bottom are broken.