#this could be a standalone minific

[terrainofheartfelt]

prompt- jenny finding out about dair and her reaction + her being happy for them

Dair + Jenny

After she hangs up the phone, Jenny stares into space for what must be twenty straight minutes. 

Her fingers twitch, needing something to do, something to keep them busy. It’s been her prime coping mechanism since, well, probably since she developed the fine motor skills necessary. If she was too hyper or bouncing off the walls, her mother put a crayon in her hand, or a pencil, or a paintbrush, and then later, fabric, thread, needles. The act of making something gave her a way to focus, to take all that ambition that had been born in her blood and do something with it. 

She grabs her sketchpad, starts on a figure and the shape of a dress without really looking at it. When she does, she realizes she doesn’t want to design anything at all, and tears the page out, a new blank one gaping up at her. 

Jenny sighs, slumping back against the wall of her dormitory, drumming her fingertips on the paper. 

She’s not…mad, not really. The way Dan talked, all cautious and careful and slow, like she was a feral cat he was trying to persuade to come out of the alley, he probably expected her to be angry, but she wasn’t. Or if she was, it feels different than the kind of anger that ate her alive back in New York. 

Not wanting to design but needing to draw something, she falls back on an old standby learned from her mother. She picks up a pen, and starts scrawling across the page, filling all the empty space, just random letters, well, maybe not so random, D-A-N, B-L-A-I-R, W-A-L-D-O-R-F, E-V-I-L S-P-A-W-N. When a sufficient amount of the page is covered, she starts connecting the lines, weaving the letters together until they’re unintelligible, a collected framework of lines, an abstract approximation of the iron outline of stained glass windows of the Anglican church down the street. 

Once satisfied with the skeletal structure, Jenny grabs her box of colored pencils. She’s meticulous, one color at a time, taking care not to use two similar hues next to each other. 

Her mom always made her own coloring sheets like this. In the evenings, after dinner but before bedtime, when Dan would disappear behind a book and Dad behind his guitar, her mom would sit in the armchair by the record player and just…color, just like this, filling an entire page with a riot of different hues and shades that did look like stained glass, so bright it reminded Jenny of the blown glass vases her parents displayed in the kitchen that she wasn’t allowed to touch.

Sometime, around the time Jenny was starting to think of herself as an artist too, she insisted that Mom show her how she made them, and she did. Jenny remembers being almost disappointed that there was no great secret to it. Scribble, connect the ends, color in the blank spaces. 

“It’s no genius work,” Alison told her, “but it’s meditative. Relaxes the mind.” 

Jenny could definitely do with that, she thinks as she picks up another pencil. Bright red, like cherry lip gloss. 

She didn’t yell. She didn’t give her blessing—because why should she—but she didn’t yell, didn’t make any accusations. She bit her tongue, and powered through the conversation best she could, sprinting to the end of the phone call. And now here she is. 

She knows what she wants to say, but she also knows that she can’t say it to Dan. 

You can’t badmouth the boyfriend. Another nugget of wisdom from her mom, delivered unto her last year, when one of her friends from show choir in Hudson started dating a grade-A douchebag, and that’s judging from Jenny’s rubric, which has a steep curve. 

Jenny couldn’t stand being around him, and more than that, didn’t want her friend giving her own time to someone who didn’t deserve it, all of which she told her mother. She and Alison undertook a thorough Full Disclosure policy when she moved to Hudson. It worked pretty well, even when Jenny didn’t like the advice she heard. 

“Honey, there’s nothing you can say that will sway her,” Alison told her. “All you can do is just love her, so when the bottom drops out she’ll know that you are there for her.”

Jenny kept her mouth shut, and, a week before senior prom, the douchebag showed his true, douchey colors, and Jenny was there for her friend. 

But what sucked is that Jenny would have been there regardless, so why should someone she cares about have to go through the wreckage of heartbreak to fall back on something they already had? 

Dan has a more resilient heart than she does. It’s just fact, they went to that school and went through their own dark forests of fucked-up shit, and while she broke down, Dan’s still there. Dan still believes, in true love, in finding the one, no matter how many times he gets hurt for the sake of the one. He’s so much like their mom, but on this, he’s his father’s son through and through.

Maybe that’s the problem. Sometimes Jenny imagines stretching her arm out over the Atlantic Ocean, plucking up her brothers by the shirt collar and carrying them over to London, to safer ground. 

But when everything got bad, she felt like she couldn’t turn to anyone, but even then Dan had been ready to punch out any one that wronged her, so long as he gave her the chance to talk and she gave him the chance to listen. So, she doesn’t want to cut him off. Even though she doesn’t know how not to, given what he’s just told her. 

So, she colors, she puts it onto the paper like her mother taught her, puts the words she couldn’t say into the phone into each swatch of color. 

She’s going to wreck you. She is going to wreck you and leave you in pieces and there isn’t a damn thing I can do to stop it. 

Half the page colored, she puts on her headphones, blasts music from her laptop. She cycles through most of Paramore’s discography by the time the page is filled.

Jenny lets out a deep breath as she examines her handiwork. Stained glass on paper. And, despite herself, it worked, like mac and cheese, like chocolate chip waffles, like any comfort from her childhood. 

On impulse, she grabs her phone, snaps a picture of her DIY coloring sheet, and sends it to Dan. She doesn’t know what to say to him, but words had always been more his thing anyway. 

Two minutes later, Dan sends a photo back, one of his own attempt, still in progress, on one of his legal pads he uses for outlining. 

Love you, she sends. 

Love you too, he texts back. 

Jenny’s still worried, but she thinks, or maybe hopes, that everything will turn out okay. 

3 years later…

Jenny and Nate stumble through the door of their Airbnb. Well, Jenny stumbles, she’s been in these heels too long. Wherever they go, no matter how fucked up they are, Nate always carries himself with an infuriating amount of athletic grace. It’s that damn pub football league. 

“Oh, couch,” Jenny sighs, collapsing onto the piece of furniture in question. It’s very comfy. They truly scored with this one, booked on a whim by Jenny while they were still on the train this morning. 

Dan and Blair had their own suite at the Plaza Athénée; when Blair heard they were staying in the 5th, she’d rolled her eyes, but even she was too happy to spend any time berating Jenny and Nate’s choice of lodging on the “wrong” side of the Seine. 

“So,” Nate says lightly, toeing off his shoes and leaving them beside her discarded boots, “how are you feeling?” He bends to pick up the coat she’d dropped on the floor next, hanging it up along with his. He takes such good care of her. 

“Exhausted,” she answers, hanging her head over the back of the sofa, as Nate drops down next to her. “Can you believe we were in a different country this morning? And we took a train underwater?”

He laughs lightly, stretching out and putting his head in her lap. “That’s not what I meant. I meant: how are you doing? About today?”

She frowns down at him puzzledly, arching an eyebrow. “Don’t you have a conflict of interest asking that question?”

“My interest is you, babe,” he reaches up, tapping the back of his hand on her sternum. “You sure you’re okay?”

“I seem to recall already having this conversation with Eric after Dan proposed.”

“Yeah, well, I’m checking in again.”

Jenny sighs, tilting her head back to think. “I’m good. Really.” She clasps Nate’s outstretched hand in one of hers, and runs the other through his hair, soft between her fingers. “I’ve had enough time to get used to the idea. And while I don’t think I’m completely used to it…” she shrugs. “The more I see them together, the more it makes sense.”

Nate makes a small hum, his little nonverbal way of saying I’m listening, and Go on. 

“I don’t know,” she takes a breath, gathering her thoughts, trying to shape them into words, “Dan’s always been just…himself, but like, in soft lines, shaded in. But…now he’s more…sharper. Like the outline of him has finally been inked in, you know?”

Nate blinks up at her, crease forming between his eyebrows. “I think so?”

Jenny laughs, and he strokes his thumb over her knuckles. “I just mean, this is the most himself I’ve ever seen him be. And if you repeat this I’ll deny it, but I think a lot of it has to do with Blair. So…” she sighs, melodramatic, “for him, I’ll suffer through being legally related to her.”

Nate snorts, face breaking into that sunrise grin Jenny loves so much. He brings their joined hands down, settling them on his chest. She’s never historically been much of a hand holder, but Nate loves it, and she loves him. And, she loves that it’s her he’s reaching for. 

“I’m happy for him,” she declares. “And I’m happy he asked me to come. And I’m really happy that we won’t be anywhere near when he tells Dad.” 

Nate makes a noise of agreement. “Or Eleanor.” 

“Oh my god, yeah.”

They both laugh, out of not only amusement at the mental image of Rufus and Eleanor’s respective reactions, but also relief, that Jenny and Nate won’t be in the blast zone when the bomb drops. There are definite advantages to the ex-patriot life. 

“Is that something you want?” Nate asks softly. 

“Facing the wrath of an Eleanor scorned? Fuck no.” 

“No,” he says softly. “What Blair and Dan did.”

“Elope in Paris?”

“Well, yeah, I guess,” he qualifies with a tilt of his head. “But I was thinking…just – marriage in general.”

“Oh,” Jenny says bluntly. 

Nate nods, his normally open expression cautious. 

Jenny sits back, thinking it over.  When Nate asks a serious question, she knows it comes after a long time of thought, always seeking an honest answer, so she tries to give him the same level of consideration. 

She’s not a believer in forever like her brother is. She’s so like their dad in so many ways, but in this one, she is her mother’s child. 

“I don’t think I’m ready for that. Maybe later. Way, way later, but not now.”

Nate nods, understanding. “I don’t think I am either.”

She lets out a breath.  

“So…” he trails off, “glad we’re on the same page?” 

She laughs. “Yeah. Yeah we are.”

She may not believe in forever, but if she had to draw it, it would look a lot like Nate. 

“And, who knows, maybe we can revisit this conversation at a later time, like…when we’re forty.” 

Nate grins, and presses a kiss to the back of her hand. “Sounds good to me.”

One word prompts

[zontiky]

I'm a moron, can you explain all the fanfic terms nice and slow for me? Sorry to bother you lmao

yeah ofc! im assuming you mean minific/drabble and such :)

drabble- i use drabble just to mean like,,, a short little fic, a quick page or so i typed out on a whim just to get a feel for a prompt or a character or how characters would interact. nothing monumental, more of an exercise of sorts, i guess? probably something from 200-500 words is a drabble

minific- a minific is a standalone thats not long enough to be its own fic but long enough to post on its own. a short fic, basically. i have a #minific tag that houses both minifics and drabbles usually, i’d say like... 500-1k words is minific length? but could be shorter, maybe around 700

ficlet- longer than a minific but i dont like it enough to call it a real fic DKSFH maybe 700-1k ish in length!

fic- usually longer than 1k words, and i like it enough to call it a finished piece of writing sdkfhsk :)))

all these are v loose terms i just kinda use how i feel like so theyre definitely not universal but... yeah :) how i label my writing (sorry if i misunderstood ur question or didnt answer it thoroughly enough! hope this helps tho <3)

[strathoa]

Demonstrating the need for speed: improving page loading and rendering in repositories

George Macgregor, Repository Coordinator, University of Strathclyde

Typical web users are growing accustomed to speed. Whenever they use any website they expect quick responses, little lag and a smooth user experience (UX). This has always been true of the web but, as time has progressed, users’ expectations have too. The importance of mobile has simply fuelled users’ impatience. Consider the following recent findings from Google:

Mobile sites lag behind desktop sites in key engagement metrics such as average time on site, pages per visit, and bounce rate. For retailers, this can be especially costly since 30% of all online shopping purchases now happen on mobile phones. The average U.S. retail mobile site loaded in 6.9 seconds in July 2016, but, according to the most recent data, 40% of consumers will leave a page that takes longer than three seconds to load. And 79% of shoppers who are dissatisfied with site performance say they're less likely to purchase from the same site again.

Other research actually found page abandonment to be far higher:

Average load time for mobile sites is 19 seconds over 3G [and] 53% of mobile users abandon sites that take longer than 3 seconds to load […] Comparing faster sites (5 seconds) to slower ones (19 seconds), the faster sites had average session lengths that were 70% longer and bounce rates that were 35% lower.

Clearly this sort of user behaviour is relevant to the work of institutional repositories, and repositories more generally. One might also argue that scholarly end users are even more likely to lack patience. Such users are often interacting with dozens, perhaps hundreds, of scholarly websites and search tools every day. They engage in horizontal information seeking strategies and simply don’t have the time or patience to wait for, say, repository pages to render. Because they are skipping across multiple, disparate sites to gather the information they need to complete their task, speed is of the essence.

On top of this consideration, it should also be noted that, by their very nature, repositories tend to experience high “bounce rates”. Avoiding unnecessary or additional “bounce” therefore has to be mitigated.

The repository speed problem

In general, repositories are slow to load pages, across both desktop and mobile. This situation is not peculiar to repositories as it afflicts many platforms, from CMS implementations to e-commerce systems. This is because it is much easier to make a standalone website speedy but much more difficult to effect speed improvements within the constraints of a larger software platform. Platforms, like repositories, simply have more stuff going on at the backend and the content being rendered on pages is often more complicated.

However, this isn’t to say that optimisations cannot be implemented because they absolutely can. And this is ultimately what this particular blog post is about: taking the page loading optimisations for our EPrints repository, Strathprints, as far as they will go.

As we shall see, it was possible to yield a 79% overall improvement in rendering for Strathprints and, with a little graft, it should be possible for other repositories, whatever flavour, to make similar adjustments to satisfy users’ need for speed. There isn’t time or space to discuss every single action in minute detail but exploring some of the principal steps below should help to give your loading times a haircut.

Observing the need for speed

As many readers may be aware, Chrome DevTools provides some excellent diagnostic tools for trouble shooting website performance issues such as HTML and CSS element problems (i.e. why is my website not rendering in the way I originally intended?); but it also provides useful tools for analysing resource loading times. Mozilla Firefox also provides similar tools. The “Network” panel in Chrome DevTools (pictured) can be used to record and analyse network activity thus allowing:

Load information in aggregate or for individual resources to be observed.

Filtering and sorting of how resources are displayed.

Visual inspection of the timeline column, which displays a visual waterfall of all network requests.

Capturing of screenshots alongside the timeline during resource loading, thereby allowing inspection of page rendering progress. (For example, not all resources may have loaded but if above-the-fold content is prioritised and visible in the screenshot capture, then the page could be said to have delivered for the user.)

Inspecting the resource loading times is really the best place to observe how repository pages are being loaded. It highlights in spectacular detail the myriad of resources (some of which being called via third-party JavaScript), their size, time spent loading, etc., as well as providing a benchmark from which subsequent page loading optimisations can be measured. The “Network” console also allows loading emulation over 3G and 4G connections within desktop and mobile displays.

Minification and rationlisation

Minification refers to the process of removing superfluous or redundant data without affecting how the resource is processed by the browser - e.g. code comments, formatting, white space characters, unused code, using shorter variable names, etc. This superfluous data may aid the human readability of the code but they are not needed for the code to execute efficiently.

JavaScipt and CSS files can be rather bloated and are generally ripe for minification. Without minification slower resource loading and ergo page loading results. Indeed, if your repository is anything like Strathprints, pages will probably be loaded with numerous CSS and JavaScript that you, as a repository manager or developer, implemented yourself! It takes only a small amount of time to implement minification and free online tools are available to help, such as CSS Minifier and JS Compress. Minification is therefore a quick win and, when applied to all the CSS, JavaScript and some HTML too, yielded a 23% improvement in page loading speeds alone for Strathprints.

But before minifying it is first necessary to rationalise any CSS. In instances where there is a “main” CSS and several smaller supporting CSS files, it is worth rationalising these supporting files into just one or two CSS files. Maintaining lots of separate CSS files has always seemed sensible to people like me because it provides for clarity and ease of work. However, it also contributes to the number of resources a browser has to request and load before displaying a page on the repository to the user. So, reducing the number of those requests and loads is critical. Rationalising multiple CSS files into, say, one or two minified CSS files therefore offers the promise of 1 or 2 seconds off page loading. (Interestingly, Google actually recommends using inline CSS to obviate CSS file loading, assuming the styles aren’t too complex; but for me this breaks the separation of concerns philosophy which makes me feel a little dirty).

And before we conclude the discussion of CSS, it is also worth reviewing how stylesheets are being called within your repository. For example, calling CSS using the @import command – used by default within EPrints – has been shown to have a negative impact on page performance, so moving from @import to <link> is something to be added to any ‘to-do’ list.

Asynchronous loading of JS resources

Render-blocking JavaScript is probably one of the most irritating obstacles to overcome when you are feeding the need for speed. A repository like Strathprints, probably like most others, needs to load a lot of JS resources in order to deliver important functionality. For Strathprints this includes native JS resources, but also third-party JS such as the Google JSAPI, AltMetric API, analytics from Google Analytics and AddThis, as well as for any EPrints plugins that have been installed from the EPrints Bazaar.

Before a browser can render a page it has to build a “DOM tree” by parsing the HTML. If the parser encounters a script during this process it has to pause to execute that script before continuing its parsing. Third-party scripts are more problematic because not only is the parser required to pause to execute the script, but it also has to wait for the resource to be downloaded too, all of which incurs network roundtrips and inevitable time delays before parsing can resume. Meanwhile, of course, the page cannot be rendered to the user because the browser is either pausing to execute scripts and/or calling scripts from other services.

However, in many cases there is no need for JS to be loaded at the same time as the page itself and therefore a lot of JS can actually be deferred until after page rendering. The good news is that HTML5 introduced the async attribute to be used with <script>. This Boolean attribute indicates that the browser should, if possible, execute the script asynchronously.

<script type="text/javascript" async="async" src="https://www.google.com/jsapi"><!--padder--></script>

Full disclosure! There is always troubleshooting to be performed when using async because the consequences of loading JS asynchronously is not always known. It can break existing functionality and have knock-on consequences for certain repository features. Quite a few “creative” solutions were sought in order to implement async on Strathprints - where there is a will, there is a way! Suffice to say, all JS in Strathprints now loads asynchronously resulting in a far speedier response on both desktop and mobile. This also has the added bonus of benefiting search engine bots, many of which choose to abandon pages with render-blocking content.

There are new W3C standards emerging soon to support the loading CSS files in a similar non-render-blocking manner. An onload declaration in the <head> for the CSS will defer their loading until the page has been rendered. There is no support for onload in browsers at time of writing but it should become available in subsequent browser releases.

gzip compression

gzip is a file format and a software application used for file compression and decompression.

All modern browsers support and automatically negotiate gzip compression for all HTTP requests and, where used, gzip can compress the size of the transferred response by up to 90%. This significantly reduces the amount of time needed to download resources, reduces data usage for users, and improves the first render time of your pages.

Enabling gzip is more an infrastructural task because it involves configuring the repository server so that it returned gzipped content to compliant browsers. This means tinkering with Apache. Something like the following should get added to the .htaccess file in Apache:

# compress text, html, javascript, css, xml:AddOutputFilterByType DEFLATE text/htmlAddOutputFilterByType DEFLATE text/xmlAddOutputFilterByType DEFLATE text/cssAddOutputFilterByType DEFLATE application/xml>AddOutputFilterByType DEFLATE application/xhtml+xmlAddOutputFilterByType DEFLATE application/rss+xmlAddOutputFilterByType DEFLATE application/javascriptAddOutputFilterByType DEFLATE application/x-javascript

# Or, compress certain file types by extension:<files *.html>SetOutputFilter DEFLATE</files>

Following an Apache restart, it should be possible to observe gzip being delivered in the HTTP response headers for the repository. This can be verified by opening Google DevTools (or your favourite alternative) as pictured.

Compression can thereafter be tested externally using the service, Check GZIP Compression, which kind of does what it says on the tin! But by enabling gzip Strathprints enjoys a 77.2% compression boost.

Before concluding on this topic it is worth giving thought to the concept of compression more generally. For example, are all images and icons on the repository compressed? Optimising images using one of many online tools allows images to strike a good balance between quality and file size.

Summary

All the optimisations discussed in this blog post are optimisations I have been intending to action for many months, perhaps even years. Whilst some of the optimisations are more problematic to implement than others, there are many which could be considered “quick wins” and which would yield significant improvements (e.g. minification).

In the case of Strathprints, it is possible to calculate - using Chrome DevTools - that there has been a 79% overall improvement in loading speed. It now takes, on average, under 1 ½ secs on desktop & LAN, less than 2 secs on a 4G connection, and between 2 and 3 secs on a 3G connection to load Strathprints. Thus, users are presented with a usable UI 79% quicker than before the enhancements. Overall page rendering has improved and the optimisations have also yielded a 94/100 on Google’s PageSpeed desktop test and 69/100 for mobile. Anything more on mobile would result in some serious hacks - and I’ve already performed a few of these already! :-)

The most significant optimisations have been implemented but, as time progresses, additional albeit smaller optimisations will no doubt be identified. Work is therefore not over. Indeed, henceforth the task will be more about the accumulation of marginal gains; identifying numerous minor optimisations that can be implemented which, when taken in aggregate, effect further significant improvements – all of which feeds the users’ need for speed.