rrssb 2.0 outline

[dbox]

https://github.com/kni-labs/rrssb/tree/2.0

• New dev folder structure: New folder structure #118
• Ajax loading of inline svgs
• New plugin style JS call w/ options
• Total counts per Would be nice if total counts can be displayed in a small box before or after the buttons #49
• Add .popup defaults - @connorwyatt
• Port resize functions from 1.x - @joshuatuscan / anyone else who can help
• Style total counts - @dbox
• Simplified index with multiple examples - @dbox
• Tiny format fixes per Single button less than 200px becomes "tiny-format" #128 - @dbox @jsmoriss
• Update readme with new installation instructions
• Separate repo for demo page - @dbox
• Kill jquery 💀 @AdamPS @adamschwartz
• Update bower.json /w proper ignores and dependencies
• Test - everybody!

Note: This is a full version update and will have breaking changes. 1.x.x will also still be available.

[connorwyatt]

By the way I've pushed my changes to my fork of rrssb and you can have a look if you like.

They dont resize yet because those functions arent in the file but I will add those in at some point

[connorwyatt]

https://github.com/connorwyatt/rrssb/tree/2.0

[connorwyatt]

There's no count yet either but that will be added

[AdamPS]

#103 ended with "I'll use the 2.0 thread from now on" so I'll pop a couple of questions / requests in here. Context is that I use Drupal and have recently become a co-maintainer of the associated module https://www.drupal.org/project/rrssb.

General requests:

• Consider the "deliver mechanism". Make it as easy as possible for downstream consumers to integrate changes. Currently the index.html is a manual integration into our PHP file. If you could deliver a PHP array that would be ideal (possibly you could use the PHP to make your index.html automatically). Taking the SVG out of index.html will be a big help in itself. The URLs in the PHP would ideally have placeholders such as [title] and [url].
• Allow extensibility by users of the library - in particular adding of new buttons. This is easy in 1.0, so just need not to lose it when moving to an SVG file or similar.
• Be ready for success and a large number of buttons. Basically take care of bloat from unused buttons. In 1.0 the CSS for every button is included in the delivery and this will gradually become significant bloat. It would be simpler if there were one CSS file without any button-specific directives. Then the button-specific CSS would ideally be delivered alongside the SVG and URL information collectively as "button data" (PHP?) from which an index.html sample can be generated. The Drupal module can take the button data in and generate appropriate files based on which buttons the user selects.
• Keep the library light-weight rather than getting bloated with many features - that's one of the key advantages that attracts people to it!

[AdamPS]

Specific question. I don't understand how you can both "use AJAX/CDN to get the SVG" and "avoid bloat of downloading unwanted buttons". Surely the client side script will fetch the full SVG from the CDN?

What I had expected was that the SVG would reside on the server, and the CMS (Drupal/Wordpress) could then see which buttons are configured and only pull in the appropriate parts of the SVG.

Simple hand-crafted sites would likely be happy with simply fetching the whole SVG so this is fine as a fallback behaviour.

[AdamPS]

Many thanks for all the hard work!

[connorwyatt]

To answer your final question first, each svg is downloaded separately and
only if the button is present so they aren't all downloaded, reducing the
bloat that would be required if all the svgs were included in the js script.
On 21 May 2015 20:45, "AdamPS" notifications@github.com wrote:

Specific question. I don't understand how you can both "use AJAX/CDN to
get the SVG" and "avoid bloat of downloading unwanted buttons". Surely the
client side script will fetch the full SVG from the CDN?

What I had expected was that the SVG would reside on the server, and the
CMS (Drupal/Wordpress) could then see which buttons are configured and only
pull in the appropriate parts of the SVG.

Simple hand-crafted sites would likely be happy with simply fetching the
whole SVG so this is fine as a fallback behaviour.

—
Reply to this email directly or view it on GitHub
#113 (comment).

[connorwyatt]

To answer your previous questions, you could use php to insert the values
by using php variables in the script tag in your HTML (not in a separate js
file as php won't run on it).

You can add your own buttons too but you will need to make an svg, and then
get the API URL for the social network. Then you can code it into the js
like the others. The reason it isn't easier is because they all have
different URL structures.

Finally, all the CSS is quite small because most of the styles apply to all
buttons, only the colour of the button is different if my memory serves so
you can't really reduce the size.

It will still be lightweight, just easier to use.
On 21 May 2015 20:41, "AdamPS" notifications@github.com wrote:

#103 #103 ended with "I'll use
the 2.0 thread from now on" so I'll pop a couple of questions / requests in
here. Context is that I use Drupal and have recently become a co-maintainer
of the associated module https://www.drupal.org/project/rrssb.

General requests:

• Consider the "deliver mechanism". Make it as easy as possible for
  downstream consumers to integrate changes. Currently the index.html is a
  manual integration into our PHP file. If you could deliver a PHP array that
  would be ideal (possibly you could use the PHP to make your index.html
  automatically). Taking the SVG out of index.html will be a big help in
  itself. The URLs in the PHP would ideally have placeholders such as [title]
  and [url].
• Allow extensibility by users of the library - in particular adding
  of new buttons. This is easy in 1.0, so just need not to lose it when
  moving to an SVG file or similar.
• Be ready for success and a large number of buttons. Basically take
  care of bloat from unused buttons. In 1.0 the CSS for every button is
  included in the delivery and this will gradually become significant bloat.
  It would be simpler if there were one CSS file without any button-specific
  directives. Then the button-specific CSS would ideally be delivered
  alongside the SVG and URL information collectively as "button data" (PHP?)
  from which an index.html sample can be generated. The Drupal module can
  take the button data in and generate appropriate files based on which
  buttons the user selects.
• Keep the library light-weight rather than getting bloated with many
  features - that's one of the key advantages that attracts people to it!

—
Reply to this email directly or view it on GitHub
#113 (comment).

[dbox]

"Consider the "deliver mechanism". Make it as easy as possible for downstream consumers to integrate changes. Currently the index.html is a manual integration into our PHP file. If you could deliver a PHP array that would be ideal (possibly you could use the PHP to make your index.html automatically). Taking the SVG out of index.html will be a big help in itself. The URLs in the PHP would ideally have placeholders such as [title] and [url]."

The new plugin js call will address this. PHP will not be used.

<body>

  <div class="rrssb-container></div>

  <script>

    var options = {
      socialNetworks: [ "facebook", "twitter", "linkedin", "email" ],
      showCount: true
    };

    $(".rrssb-container").rrssb( options );

  </script>

</body>

[AdamPS]

Well be careful with "each svg is downloaded separately" because I think it could impact the page load speed - each file to download adds an overhead: bytes sent to establish a new socket and also the socket transfers slowly when it starts up due to discovering the available speed.

Maybe better for the server to run the smarts and serve a single file containing the right icon set? Or at least allow this as an option? I.e. a config parameter that could be set to point to URL of an SVG container or similar.

[AdamPS]

@dbox the plugin js call sounds good!

[AdamPS]

Thanks again for listening. One more general consideration: what about the fallback if scripts aren't enabled? I think it ought to be at least some sort of list of buttons that are links and contain text. This is potentially important for:

• search engines and bots
• screen readers
• older/low-end devices
• bugs/compatibility problems meaning scripts don't load

I gather that kni-labs write high-end flashy websites, which is great. But I'm more into generating simple small websites fairly frequently. They don't have a lot of personal attention each so simple is good! Some of my clients have 8-year old devices themselves!

[AdamPS]

It looks to me as if the the CSS is currently close to 500 bytes per button - nearly 50% of the SVG size.

Some other well-established social share solutions have around 100 buttons.

[connorwyatt]

I agree with @dbox, no php will be used but you can use php to insert the
social networks into the js options. That would be up to you though.

I'll look into the overhead of establishing multiple connections but
without multiple connections it would need php or another server side
script to do the job.

Remember that with the CSS the base styles are most of the file, the
specific styles are only a tiny part, meaning that adding new social
networks would add minimal code to the CSS.
On 21 May 2015 21:29, "AdamPS" notifications@github.com wrote:

It looks to me as if the the CSS is currently close to 500 bytes per
button - nearly 50% of the SVG size.

Some other well-established social share solutions have around 100 buttons.

—
Reply to this email directly or view it on GitHub
#113 (comment).

[connorwyatt]

I don't personally work with kni labs but I do work with websites with a
lot of js, and you'll be glad to know that seo is not a problem as google
now runs js and indexes.

For older devices, a simpler solution might be your best bet (e.g. the idea
you had in another thread about moderately responsive buttons).

I personally don't write code for old browsers, I just use a piece of code
that let's older browser users know that their browser is out of date and
that the site may not work properly. I'm not a big fan of supporting ie8 or
below.

If you want to write a fallback for non js users then you could do that but
that isn't something I would personally do.
On 21 May 2015 21:23, "AdamPS" notifications@github.com wrote:

Thanks again for listening. One more general consideration: what about the
fallback if scripts aren't enabled? I think it ought to be at least some
sort of list of buttons that are links and contain text. This is
potentially important for:

• search engines and bots
• screen readers
• older/low-end devices
• bugs/compatibility problems meaning scripts don't load

I gather that kni-labs write high-end flashy websites, which is great. But
I'm more into generating simple small websites fairly frequently. They
don't have a lot of personal attention each so simple is good! Some of my
clients have 8-year old devices themselves!

—
Reply to this email directly or view it on GitHub
#113 (comment).

[connorwyatt]

By the way with regards to the fallback, the rrssb container gets emptied before adding the buttons (in the 2.0 I'm writing) so you could add a fallback in there and if the script runs it will remove the fallback

[Marc-pi]

@AdamPS
you have great library to manage compat : modernizr, respond, html5shiv etc...
just use them. rrssb must work at state of art on stabilized techs.

yes, all serious search engines are reading now JS, google being at front of them

[AdamPS]

Thanks all for continuing to listen. I guess I'm a bit old fashioned on scripts - I'll bow to your wisdom.

Regarding the CSS size though please can you double-check? I just tested and my result was that 67% of the file was the specific parts. Presumably this number will increase over time as more buttons are added?

[connorwyatt]

Apologies, I haven't looked yet, I will now
On 21 May 2015 22:30, "AdamPS" notifications@github.com wrote:

Thanks all for continuing to listen. I guess I'm a bit old fashioned on
scripts - I'll bow to your wisdom.

Regarding the CSS size though please can you double-check? I just tested
and my result was that 67% of the file was the specific parts. Presumably
this number will increase over time as more buttons are added?

—
Reply to this email directly or view it on GitHub
#113 (comment).

[dbox]

We may be able to rewrite the each loop to be a little more efficient.

[connorwyatt]

Just looked, I was thinking of the scss rather than the css. I'm not aware of a way round it though so it's going to have to stay like that. You could always remove rules you don't need

[connorwyatt]

@dbox I was just thinking that but I don't think you could unless you change some of the colours to be the same, eg Facebook and LinkedIn but I like the slightly different shades to be honest

[AdamPS]

It's possible that my aims are a little bit different from yours - but also I think I might be able to help you get the best of both worlds. Please let me know if I'm not helping, and I'll leave you in peace!

[AdamPS]

CSS: close to 500 bytes actually contains 3 bits of real information: normal color; hover color; tiny hover color. Why not have the js file store these three colours in a config array and then inject the CSS?

[AdamPS]

SVG files: I think there is a lot of evidence against fetching separate files: many articles; tools such as YSlow; feedback from users of the Drupal RRSSB module; the links I sent in my original issue - it seems like a step backwards from v1.0.

I expect it is faster to embed all the SVGs in the JS (like you say they are fairly compact).

But even better is to let the server-side code send only the data for the chosen buttons - I'll explain more in a mo...

[connorwyatt]

CSS injection isn't a bad idea, I'll test both methods of loading the SVG's and in the future I might look into writing a php version as you are right that server side includes would be a better bet, you'd still want the js though for the behaviour

[AdamPS]

HTML: so if I understand correctly, the base page will just be a placeholder which the JS populates with list items. (Maybe I'm old-fashioned to prefer my HTML in-line then the script to style more like Superfish etc). If you are going this way beware that users may currently be customising the HTML and so you might lose that flexibility.

In particular don't assume that URL for sharing is the current page URL or title is current page title. This breaks in a feed / if content is embedded / if the current URL isn't canonical etc.

Secondly, some of the sharing buttons require extra parameters. E.g. youtube can't really share a page so the Drupal module allows configuration of the user's channel. And pinterest needs an image to be supplied etc.

[connorwyatt]

Yes that is all being supplied, I've already written that in, check my 2.0 branch on my for of the project.

You can specify pinterest media, youtube link and github link

[connorwyatt]

And whilst I understand that some people prefer inline html, the jquery plugin call using .rrssb() means that you can set it up in seconds rather can copying html into your pages

[dbox]

ah. perfect.

[connorwyatt]

;)

On 22 May 2015, at 19:58, Daniel Box notifications@github.com wrote:

ah. perfect.

—
Reply to this email directly or view it on GitHub #113 (comment).

[connorwyatt]

There you go, my github pages version has the K and M functionality now

[dbox]

@connorwyatt Did you want me to pull into 2.0 or do you want to get a little further first?

[connorwyatt]

You can pull it in just let me check whether I need to push anything up.

I haven’t done anything with the sizing of the buttons yet so that is the next job that needs doing.

On 27 May 2015, at 18:34, Daniel Box notifications@github.com wrote:

@connorwyatt https://github.com/connorwyatt Did you want me to pull into 2.0 or do you want to get a little further first?

—
Reply to this email directly or view it on GitHub #113 (comment).

[bboerendans]

The thing why http://graph.facebook.com/?id=http://connorwyatt.github.io/rrssb/ and http://graph.facebook.com/?id=http://kurtnoble.com/labs/rrssb is giving the same count is that in both pages the meta property="og:url" have the same url :)

[dbox]

@bboerendans That's what we thought too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/

[connorwyatt]

Yeah we checked that @bboerendans and it’s not that, I have no idea what to do with it but I’ll look into it.

No URL is hard coded into the js so I can’t see why it’s playing up

On 28 May 2015, at 13:26, Daniel Box notifications@github.com wrote:

@bboerendans https://github.com/bboerendans That's what we thought too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/ http://dbox.us/rrssb2/
—
Reply to this email directly or view it on GitHub #113 (comment).

[dbox]

I have an idea. Standby
On Thu, May 28, 2015 at 7:40 AM Connor Wyatt notifications@github.com
wrote:

Yeah we checked that @bboerendans and it’s not that, I have no idea what
to do with it but I’ll look into it.

No URL is hard coded into the js so I can’t see why it’s playing up

On 28 May 2015, at 13:26, Daniel Box notifications@github.com wrote:

@bboerendans https://github.com/bboerendans That's what we thought
too but I put a page up with no og:url meta and it's still doing it:
http://dbox.us/rrssb2/ http://dbox.us/rrssb2/
—
Reply to this email directly or view it on GitHub <
https://github.com/kni-labs/rrssb/issues/113#issuecomment-106295026>.

—
Reply to this email directly or view it on GitHub
#113 (comment).

[dbox]

@connorwyatt. Thanks! If you could bring in the current resizing that would be best.

[dbox]

@bboerendans @connorwyatt. Haha. So we were all right about the og-title. When I originally uploaded it, it had the og-title, then I took it off. Evidently all it takes is seeing it once and it caches it, even if you remove.

http://www.dbox.us/rrssb/

@connorwyatt - I think it's safe to assume script is all good. :)

[connorwyatt]

Cool, I would have been absolutely stumped otherwise.

Seems like a strangely permanent system though!

On 28 May 2015, at 15:04, Daniel Box notifications@github.com wrote:

@bboerendans https://github.com/bboerendans @connorwyatt https://github.com/connorwyatt. Haha. So we were all right about the og-title. When I originally uploaded it, it had the og-title, then I took it off. Evidently all it takes is seeing it once and it caches it, even if you remove.

http://www.dbox.us/rrssb/ http://www.dbox.us/rrssb/
@connorwyatt https://github.com/connorwyatt - I think it's safe to assume script is all good. :)

—
Reply to this email directly or view it on GitHub #113 (comment).

[dbox]

https://developers.facebook.com/tools/debug/og/object/

[dbox]

@connorwyatt You still working on stuff?

[connorwyatt]

Hi @dbox, at the minute I'm not as I've just started a new job, it's currently in a state where it loads the svgs using ajax and you can use it via jquery, it just doesn't resize.

Feel free to add in the resizing functions, the old ones should be fine, you would just need to change element names and classes. Otherwise I won't get round to it in the next month and it might be longer.

-------- Original message --------
From: Daniel Box notifications@github.com
Date:19/06/2015 16:17 (GMT+00:00)
To: kni-labs/rrssb rrssb@noreply.github.com
Cc: Connor Wyatt cw@connorwyatt.io
Subject: Re: [rrssb] rrssb 2.0 outline (#113)

@connorwyatt You still working on stuff?

—
Reply to this email directly or view it on GitHub.

[adamschwartz]

Hey @dbox, I really dig what y’all have built. I’m wondering if in 2.0 you might consider dropping jQuery as a dependency?

If you wanted to still support $.fn.rrssb you could bring that in if jQuery is detected. That way the advantages of using it with jQuery could be maintained while still allowing it to be used by websites which don’t use jQuery.

I’d be happy to help out if this is something you’re interested in doing.

[AdamPS]

So is your long term plan to drop v1.0?

I entered the debate further up the thread from the perspective of the co-maintainer of the Drupal integration. I don't want to rerun the discussion again, but just a quick summary. I can see that the drop-in zero integration option is attractive to many people. But having the js generate the content is somewhat breaking the CMS model. With v1.0, the HTML in Drupal starts off as an array and gradually gets expanded to the final HTML, with dozens of opportunities for customisation via hooks, templates, translations etc. Some people are using these. Also I believe our users are attracted by the fact the V1 module doesn't download a separate file per image - it is much more lightweight than comparable Drupal modules. I know, you said V2.0 is super fast on a modern developer PC, but maybe it makes a difference over a slow broadband. Certainly there are plenty of articles that say a single file is better performance. I have a prototype roughly working with Drupal auto-generating a CSS file with SVGs as background images (hence better caching compared with inline SVG) although unfortunately can't do the micro format at the moment, so maybe I need to look at other ideas.

So net of all that is that I'm not sure how v2.0 would fit into the Drupal module. Do you think there is any way that the two approaches can live side-by-side in the same project? Clearly there is a fair overlap. Or if we aren't sure about v2.0 would you suggest that we fork and go our own way? I don't know what the original author of the Drupal module would say - maybe he would be more happy about the new V2.0 approach, but it's less good for my websites.

I can potentially help if we can find the side-by-side approach. Although I mostly do php/CSS, and don't know much javascript, so I might not have the skills you are looking for.

[dbox]

@adamschwartz Personally, I don't mind dropping it as I don't do the JS updates. Would need to run by @joshuatuscan and @connorwyatt. I guess I'd just need to see some data on what % of people use jquery and what the ramifications of removing it are.

[dbox]

@AdamPS 1.x will still be available, but I doubt we'll maintain it to the level that 2.0 will be. Definitely happy to have rrssb-drupal and rrssb-wp forks off the main repo, but I personally have zero interest in maintaining all the different versions. At a certain point, people like to build things differently, and that's okay!

[AdamPS]

@dbox Great, thanks it will help to have 1.0 around still. I can understand it would be less well maintained. Any updates to SVG files would perhaps be a really useful thing to transfer across and hopefully really easy to do as the files will stay in sync.

[adamschwartz]

@dbox I’m not sure why jQuery usage data would be necessary. Removing jQuery as a dependency would allow more people to use it, not fewer. That being said, the development time to remove it as a dependency (and continue to maintain it that way) is certainly real, but I’d be happy to help out there.

@joshuatuscan @connorwyatt thoughts?

[dbox]

I just meant if 99% of people are using it, then probably not worth the
refactor, but I'm game.

We just gotta port those resize functions over first.

On Fri, Jul 24, 2015 at 11:46 AM Adam Schwartz notifications@github.com
wrote:

@dbox https://github.com/dbox I’m not sure why jQuery usage data would
be necessary. Removing jQuery as a dependency would allow more people to
use it, not fewer. That being said, the development time to remove it as a
dependency (and continue to maintain it that way) is certainly real, but
I’d be happy to help out there.

—
Reply to this email directly or view it on GitHub
#113 (comment).

[adamschwartz]

Ahhh, I see, my mistake.

Yeah, as co-creator of YMNNJQ I may be just a tad biased ;), but when a library can do everything it wants without jQuery, I typically advocate it. And like I said, I’d be happy to help out as I see it being very beneficial here. IMHO, a typical blog wouldn’t need jQuery since it’s just displaying static posts. Things like comments can be handled by Disqus, and Social Sharing can be handled by RRSSB :). One thing that drew me to RRSSB from the beginning was how lightweight it was as compared many other similar tools out there. At the time I didn’t realize that jQuery was a dep though. With jQuery added in, RRSSB’s size is an order of magnitude larger. Anywho, sorry again for my earlier confusion.

[AdamPS]

From the Drupal perspective, jQuery will very likely be loaded anyway. But there is a certain amount of hassle to get v10 that is required here - the default is lower.

[joshuatuscan]

I think it’s a good idea to abandon jQuery as a dependency. Originally it was for speed and banking on the fact that most people will have jQuery running on their site already, however, vanilla JS would be better and I’m for it.

Like Daniel said, just need to port the functions away from using it.

On Jul 24, 2015, at 10:40 AM, Adam Schwartz notifications@github.com wrote:

Ahhh, I see, my mistake.

Yeah, as co-creator of YMNNJQ http://youmightnotneedjquery.com/ I may be just a tad biased ;), but when a library can do everything it wants without jQuery, I typically advocate it. And like I said, I’d be happy to help out as I see it being very beneficial here. IMHO, a typical blog wouldn’t need jQuery since it’s just displaying static posts. Things like comments can be handled by Disqus, and Social Sharing can be handled by RRSSB :). One thing that drew me to RRSSB from the beginning was how lightweight it was as compared many other similar tools out there. At the time I didn’t realize that jQuery was a dep though. With jQuery added in, RRSSB’s size is an order of magnitude larger. Anywho, sorry again for my earlier confusion.

—
Reply to this email directly or view it on GitHub #113 (comment).

[adamschwartz]

@AdamPS a great example of why dep management on the web is so hard. 👍

@joshuatuscan awesome! Let me know if I can help at all.

[dbox]

Checklist at the top of this thread has been updated with some tasks:)

This one is the main priority right now:

Port resize functions from 1.x - @joshuatuscan / anyone else who can help

Not sure about @joshuatuscan's current availability, so if anyone else can dive in and help feel free!

[dbox]

Btw, 2.0 is DELIGHTFUL to work on thanks to all @connorwyatt's work on the gulp/browsersync setup.

[dbox]

Pinging to see availability on 2.0 work. @joshuatuscan you around at all? Anyone else want to dive in here? I'm currently slammed but would like to get 2.0 out the door if possible. I can help but can't take on the porting of resizing functionality.