afschwartz

You absolutely can! I used to teach an informal free class on CSS (http://magicofcss.com). Even though I wasn’t a teacher at any actual school GitHub kindly gave me and my students access to free private repos for educational use. (See https://education.github.com/guide for more information.)

While I fully support the ability of using an `install` property in a `package.json` as an alternative, as a frequent author of package.json, bower.json, component.json, and install.json files, I feel confident saying that install.json is a slightly different situation. Take github.com/HubSpot/Offline for example:

The package.json [1] and bower.json [2] share a lot of the same information: `name`, `version`, `authors`, and `description` are duplicated properties in both. Furthermore, updating the `version` property in a file in Git isn’t always necessary when you can create tagged releases with version numbers.

`install.json` doesn’t have the “Ugh, now I have to add the same information in a new place”-problem because it introduces two new root properties, namely `resources` and `options`, which do different (and very useful) things from the properties in these other json files. These properties define respectively the resources to include in a page when “installing” the app, and the JSON options to provide the app upon its initialization. They allow for a common way that JS and CSS resources be included in pages, which is a useful thing for the community to start to standardize around, even if this isn’t the perfect thing yet.

[1] https://github.com/HubSpot/offline/blob/master/package.json

[2] https://github.com/HubSpot/offline/blob/master/bower.json

Hey, I‘m Adam, and I designed this page. Thank you so much for this feedback.

When building this page, I definitely struggled with what to put where. The Steps 1, 2, 3 are hopefully clear about what action to take, but I agree that more motivation at the top would be great.

Here’s the thing we believe can be made easier:

When my co-founder and I built Pace [1], Offline [2], Shepherd [3], etc. [4], one of the problems we came across was that while we could get stars on GitHub, non-developers struggled to get the benefit from these projects. Often, the step they struggled with was adding the `<script>` or `<link>` tags to their page, and configuring any of the options these apps/widgets/plugins had.

Our About page [5] explains something to this effect, but bringing some of that motivation to this landing page seems like a good place to start. Thanks again! I hope this was helpful.

Perhaps in addition to:

“Anything you can include in a <script> tag can be installed through our UI.”

We could add:

“Example: You wrote a JavaScript library which works by having the user paste a `<script>` tag in their page. With Eager, instead you users can install your library by simply clicking a button.”

[1] http://github.hubspot.com/pace/docs/welcome

[2] http://github.hubspot.com/offline/docs/welcome

[3] http://github.hubspot.com/shepherd/docs/welcome

[4] http://github.hubspot.com

[5] https://eager.io/about

Shows a number of visualizations based on the sound input. There's a HUD that pops up if you visit:

http://party.github.io/tv/?welcome

I'm not seeing any scrolling of the right pane in Chrome on Mac OS. What browser/OS? Also, a screenshot or screencast might be helpful. Thanks though! (Feel free to report https://github.com/adamschwartz/magic-of-css/issues/new too if you'd prefer that.)

One of the main things we're advocating is to consider not depending on jQuery when building an open-source project.

For Offline, PACE, Odometer, Tether, and many of our other OS projects (http://github.hubspot.com), we chose not to depend on jQuery because it means our libraries can be smaller and more people can use them.

We're happy and proud to use jQuery when building an application. As many other commenters have noticed, it can be extremely useful at reducing code complexity—and let's just say it: it can make it more enjoyable to write front-end code!

That's why it's called You_Might_NotNeedJQuery. ;)

Thanks for the feedback!

It uses a lot of `transform: translate`s so it can jitter if your GPU is taxed (or if your CPU is taxed and your browser doesn't accelerate).

The duration is supposed to be 500ms though. I agree that's a little slow. I dropped it down to 360ms: https://github.com/HubSpot/drop/commit/10d1b0b324c1538bc46ee...

Let me know what you think!

Browser support is listed in the documentation (http://github.hubspot.com/sortable): IE8+, Firefox 4+, Current WebKit (Chrome, Safari), Opera.

This is intentional. Since that is an "Other" category, I elected to force it to the bottom of the sort order by setting `<td data-value="0">` for that column.

See: https://github.com/HubSpot/sortable/blob/e07209b89deac83950c...

See my earlier comment (https://news.ycombinator.com/item?id=6841944) for more info, but yeah, we agree.

With most of our open-source projects at HubSpot (http://github.hubspot.com), we've tried to keep things modular and small, doing one thing as well as it possibly could be done.

Adding filtering and searching (fuzzy, regex, etc.) is definitely something we'd like to add. (https://github.com/HubSpot/sortable/issues/4) ;)

Yea, more-or-less.

Here is a short summary of some of the major changes:

– Tables with `data-sortable` attribute are automatically initialized.

– The sort arrows are made with CSS-border triangles instead of special characters.

– The sort arrows are always present but hidden for non-sorted columns so that columns don't resize when sorting.

– `sorttable_`-prefixed class names are now `data-` attributes, so they are valid HTML5.

– The library doesn't attempt to recognize date formats. Instead, it recommends you add `data-value="#{ timeInMillis }"` to your <td> containing a human-readable date string.

I'm sure there are more that I can't think of at the moment, but that's a decent list.

It's a fair criticism. We really wanted to nail the very common use case of: "I put a small table in a blog post and I want it to be sortable and look good."

But I think you're right that it would be great to have a pairable tool which adds filtering and possibly another which adds client-side pagination.

I think these two earlier comments summarize my opinions pretty well:

https://news.ycombinator.com/item?id=6691171 https://news.ycombinator.com/item?id=6690477

Flat UI is not about beautiful color palettes.

Sure, color is an important tool at the disposal of a designer. But so are typography, layout, proportion, symmetry, hierarchy, contrast, and affordance. And those are just the static things! Designing good interactions additionally requires consideration of speed, motion, order, and timing.

Good design takes into account these qualities whether it's flat or not.

Thank you.

[Edit] ...and yes.

I totally agree. There's a big reason why "Flat" is in quotes. :)

From my perspective, the idea behind the bookmarklet is more of a way to give people a hint into what their site could look like if they decided to redesign it flat.

Of course there are many functional uses of depth which aren't purely for aesthetics or skeuomorphism. For people who already understand that distinction, it's fair to say this bookmarklet has less value.

But I think there's a pool of people who never considered designing their site flat. This gives them a quick way to see something like that.

I think that's a fair point. humans.txt is fantastic.

However, the small cost you pay for including Signet gets you a more convenient and more discoverable way for a developer visiting your site to learn about you, the author. Is the cost worth that slight convenience? Definitely a toss up and will depend on the application and its needs.

Browser support is listed in the README. https://github.com/hubspot/signet#support

I'd love to add additional support for Firefox. But unfortunately, Firebug doesn't support the full set of CSS properties in the console that are needed to pull off this effect.

That being said, we're open to PRs if you have a solution for FF!

Edit: We're working on the SyntaxError and MutationEvent warnings you mentioned. Follow here: https://github.com/HubSpot/signet/issues/3

It provides a way for developers to communicate with each other in a developer channel.

Wouldn't it be both exciting and useful to be able to open the console of nearly any site and immediately get a link to the code or author on GitHub? Sometimes these sorts of links aren't appropriate on the site itself, especially in the case of contract/client work.

That being said, performance is very important. Which is why we kept Signet small. signet.min.js (https://github.com/HubSpot/signet/blob/master/signet.min.js) is 5kb (smaller if gz) and has no dependencies.

As one anecdotal data point: I recently added Signet to my personal site and it had no impact on page load time.

If either the native offline event fires (where supported) or a single XHR request has a timeout or error, we fire our offline event, which triggers the UI to update.

So in your example, you'd know almost immediately after you clicked the "Send" button.

It's very interesting. When animating from 12 to 34, we'll animate the 2 through 22 digits to reach 4. However, when animating from 12 to 3004, we don't spin the 2 through 2992 digits. Instead, we skip digits artificially based on a target frame rate. (Since the animation is supposed to take 2 seconds, at 60fps we have 120 frames to show those digits, so you're not going to see all 2992 anyway.) We originally set this target frame rate to 60. We recently dropped it down to 30 in an attempt to improve the perceived FPS in Chrome. (See https://github.com/HubSpot/odometer/commit/fc5ca1572d0ad218c...)

We'd certainly love to hear from the community if there are any other approaches worth trying. For those interested, we have an issue tracking rendering performance here: https://github.com/HubSpot/odometer/issues/3

For those curious, here's how that's done: https://github.com/HubSpot/odometer/blob/ef4a0f9b56b715b7f00...

I agree. Thanks for the suggestion. https://github.com/HubSpot/odometer/commit/927b5e35cbe9d4071...

View the demo here: https://github.com/public-contributions

We were inspired by a number of sources. We loved NProgress when it came out, but felt that mixins `Nprogress.set` calls into our code was cumbersome. After we started work on (what was originally codenamed MProgress (https://github.com/adamschwartz/mprogress) ;), Codedrops published their article. We were psyched because we thought we had an even bigger opportunity. So we curated and crafted the best themes from all over the web (Codedrops, included) and coupled them with the easiest-to-configure progress bar solution out there.

We totally agree. PACE doesn't block or change the rendering of the page at all. You should use PACE if you want to provide your users with additional information about the progress and activity of the page load and future ajax requests.

This should fix the issue your seeing: https://github.com/HubSpot/vex/commit/0649f2eedf406a7347f6ef...

Thanks! https://github.com/HubSpot/vex/commit/5ce17fccca4df92009ca43...

Update to Chrome 26 (latest stable)