#hypothes.is

<seanh> nick: Thanks for the write-up

<seanh> You can get a surprisingly good result by doing view source on the http://hypothes.is|hypothes.is front page and copy-pasting it into a jinja template in the pyramid app

<seanh> Then just walk through the code tidying it up, moving resources like css locally, etc

<nick> So are we doing our standup?

<robertknight> Just created a hangout

<nick> (This should be automated.)

<robertknight> https://plus.google.com/hangouts/_/hypothes.is/...

<nick> https://hypothes.is/wp-content/uploads/fbrfg/fa...

<nick> https://hypothes.is/wp-content/uploads/fbrfg/ap...

<robertknight> The full gory details of exactly how Via rewrites pages: https://gist.github.com/robertknight/2145c99ed8...

<seanh> For fetching the WordPress feed into the app - this could be written as a completely standalone script that fetches a feed from a URL and pushes the items to an API endpoint provided by the app, cou

<seanh> couldn't it?

<seanh> So it would take the feed URL and API URL as command-line args, and an h username and password

<seanh> This "add a blog post" API would be admins-only of course

<seanh> The nice thing about that approach is the code is really simple and standalone, we run it as an hourly cron job on any server, but you can also do one-off runs of it against production h on your laptop if you want it to update now, and you can also run it against a dev instance easily

<nick> @seanh: yep, that would work

<seanh> It's also easy to do a temporary quick fix is the feed parsing messed up somehow, just post to the api directly

<nick> but while it's nice to be decoupled, it's also more of a PITA operationally

<nick> (vs. just deploy the app and it works)

<nick> anyway

<nick> I don't think we need to worry about that until someone decides it needs doing

<seanh> Can't we make this the same operationally? Ship the standalone script in the git repo, and it to the Procfile?

<seanh> Sure

<nick> @robertknight: having a bit of a GitHub clearout in anticipation of Alice joining us, and found this: https://github.com/hypothesis/viewer-prototypes

<nick> might be of interest to you?

<nick> prototypes for improved card-to-document position mapping that never got followed up on

<seanh> Just noticed that if you refresh the page, the "Install" (Chrome extension) button is initially a "Get bookmarklet" button then changes to install after a second

<seanh> Or not depending on your browser

<seanh> If the browser detection is based on HTTP headers then we can improve on that by moving it to server-side templating

<robertknight> nick: Thanks, I'll have a look at some point

<robertknight> seanh: Yes, I'd suggest using a trusted lib if we do any User-Agent sniffing

<robertknight> Since for compatibility, Microsoft Edge for example includes 'Chrome' in its UA string

<seanh> I'd heard about those prototypes but never found them - they're pretty cool

<robertknight> seanh: An alternative approach might be to keep the button client side but use the presence of the inline extension install APIs to show the buttn

<seanh> If there's a good way to do this server-side without javascript, and without any "flash of wrong (or no) button" on page load, that's gonna be best

<seanh> May be caching issues?

<nick> this is a reasonably common pattern in progressively enhanced pages

<nick> the usual thing to do is to hide the element with JS as soon as possible, then unhide when the HTML inside has been set up correctly (e.g. with an "Install Chrome extension" button for Chrome users)

<nick> tbh that's probably overkill here

<nick> a second's pause probably indicates something is going a bit wrong

<nick> Or we could just show everyone the "Install Chrome extension" button

<robertknight> If you ever do want to do server-side UA sniffing for a good reason, something like https://github.com/selwin/python-user-agents may be useful

<nick> and have it link to the Chrome store by default, but set it up for inline install if we detect Chrome

<robertknight> One potential use case is (for UA sniffing) is moving the ES5/6 polyfills into a separate bundle which is not sent down to sufficiently new browsers.

<nick> let's fix one problem at a time, folks :)

<nick> Sean was asking about the "Install Chrome extension" button, if I understood correctly?

<robertknight> Yes, of course ;)

<nick> I'm a bear of little brain and get confused easily.

<seanh> For that button, the best fix is gonna be server-side UA sniffing, no?

<nick> @seanh: almost certainly not, sadly

<nick> because detecting Chrome reliably from a U-A string is going to be next to impossible

<seanh> Or we get a new design that is the same in all browsers

<nick> I reckon the best bet (at least for now) is to show it always, as a link to the Chrome store, and "upgrade" it to an inline install button if we detect the `chrome.webstore.install()` API is available.

<nick> at least until we have other browser extensions.

<seanh> Wait, it's always just a link now, isn't it? (Even in Chrome)

<nick> Yes, which is sad.

<nick> We can of course just do what we're doing now -- there shouldn't be any reason why it would take a full second to switch to the Chrome link.

<nick> It might be worth investigating why that is before doing anything else.

<seanh> The thing that it does now is link to the Chrome extension in a big button, then to the bookmarklet in some small text beneath. But if you're in Firefox then the bookmarklet goes into the big button and the Chrome extension into the small text, it swaps them

<nick> Yep.

<nick> There's no reason there should be a delay in doing that.

<nick> It should be perfectly possible to put the JS that swaps out the button immediately after the button (all it needs to do is check for the `chrome` global), which should be more-or-less instantaneous

<seanh> I'm just wondering how much we care about that swapping at all?

<seanh> Can we change to a design that's just the same in all browsers?

<nick> We can, but that's potentially worse for non-Chrome users.

<nick> The problem you identified was the delay.

<nick> So let's fix that.

<nick> The correct way to fix that is a small piece of code in the `head` which adds a `js` class to the body.

<seanh> _Arguably_ it's worse for non-Chrome users, arguably not. Maybe it's good for them to see the big Chrome extension link, rather than have it in tiny text where they might miss it

<seanh> Anyway, sure, I'll keep it the same for now then

<nick> Well I also proposed a solution that looks the same in all browsers.

<nick> Take your pick!

<nick> I really don't mind

<nick> I'm just pointing out that the delay doesn't have to be a problem if you do PE properly.

<seanh> there's a link to showhighlights.js in the front page that seems to be a broken link

<seanh> Gonna remove it, anyway

hypothesis/h#9086 (trello-178-new-homepage - 9d0d843 : Sean Hammond): The build passed.

Change view : https://github.com/hypothesis/h/compare/0258dd3...

Build details : https://travis-ci.org/hypothesis/h/builds/93181638

<nick> just going to do some minor fiddling with our monitoring, so not to worry if some alerts fire

<seanh> Anyone happen to know if `window.chrome` is defined on Chrome for Android?

<robertknight> seanh: Not sure, give me a couple of mins

<seanh> It looks like the current front page shows the bookmarklet button (rather than the Chrome extension one) on Chrome on Android, though I'm not sure (don't have an Android device to test on)

<nick> Argh. I keep forgetting to ask people to add `CHANGES.txt` entries in pull requests...

hypothesis/h#9091 (remove-show-unanchored-feature - c6e7844 : Nick Stenning): The build passed.

Change view : https://github.com/hypothesis/h/commit/c6e78441...

Build details : https://travis-ci.org/hypothesis/h/builds/93229044