#i tag & em tag in html

[bruuberrycc]

Guia COMPLETO de como deixar os GRÁFICOS do The Sims 2 MODERNOS!

✨ Link do vídeo: https://youtu.be/6ofGeyhWIQ8

Lembre-se que os itens vão na pasta DOWNLOADS, se não existe na sua pasta, abra o jogo e saia. Caso ainda não esteja lá, crie uma pasta chama 'Downloads', como ensinei no vídeo. Depois você precisa ativar os conteúdos personalizados como fiz no vídeo.

Também tenha em mente que os itens foram defaults/de substituição, você deve baixar apenas um arquivo.

MOD CLEAN UI:

https://greatcheesecakepersona.tumblr.com/post/190825573525/download-clean-ui-post-updated-011121

tutorial para quem tem ultimate colection ou 🏴‍☠️ do Mr DJ (se o seu é 🏴‍☠️ do anadius, vc usa a vers��o legacy, ou seja, a mesma que a minha): https://www.youtube.com/watch?v=IvOj_1A7MDA

ÁRVORES:

https://criquette-was-here.tumblr.com/post/631601714436423680/basic-linden-trees-redux-default-replacements

https://sixfootsims.tumblr.com/post/640878205133275136/well-heres-my-first-post-on-this-blog-so-i

https://lowedeus.tumblr.com/post/638682683409596416/tscs-seasonal-pines-as-base-game-nhood-pines

CÉU:

https://lowedeus.tumblr.com/post/163917091786/victory-over-the-sun-invisible-realistic-sky

https://lowedeus.tumblr.com/post/163111276336/every-july-we-celebrate-a-very-special-date

FUNDO DA VIZINHANÇA:

https://greatcheesecakepersona.tumblr.com/post/158813484310/download-post-updated-on-14042017-see-the

https://greatcheesecakepersona.tumblr.com/post/180760734605/download-city-rural-skyline

GRAMA:

https://criquette-was-here.tumblr.com/ (a grama que uso)

https://curiousb.dreamwidth.org/28103.html

https://siletkasims.tumblr.com/post/136087319102/i-made-very-small-edits-to-curiousbs-default

ÁGUA:

https://modthesims.info/d/587597/pond-amp-sea-water-overhaul.html

RUA:

https://curiousb.dreamwidth.org/28103.html

https://criquette-was-here.tumblr.com/

https://gardenofshadows.org.uk/gardenofshadows/index.php?topic=37429.0 (a rua que uso)

DEFAULT SKIN, OLHOS, CABELOS E ROUPAS

https://sims2defaults.dreamwidth.org/

https://gryning.tumblr.com/post/722213048441520128/final-duet-skinblend (a skin DEFAULT que uso)

https://www.tumblr.com/acottonsocksims2/775227183173124096/ara-fusilli-hello-redundancy-my-old-friend-in?source=share (o olho DEFAULT que uso)

CÍLIOS 3D (não é default, mas são mais bonitos que os 2D)

https://modthesims.info/d/680833/3d-eyelashes-eu-cu-update.html

PACKS DE DEFAULTS DE CABELO:

Esses arquivos são pack que possuem praticamente todos os defaults de cabelo, OU SEJA, você pode baixar apenas um entre dessas duas opções abaixo e não pode baixar outros cabelos defaults avulsos. Caso queira substituir algum, analise bem e procure pelo nome do cabelo no sims2defaults, procura na sua pasta e exclua, depois disso, pode baixar outro cabelo do mesmo default.

Clay Hair (estilo The Sims 4): https://platinumaspiration.tumblr.com/post/735878637799260160/when-i-say-basically-everything-i-mean-basically

Mikexx2's hair system (alpha misturado com maxis match): https://spookymuffinsims.tumblr.com/post/611290311879180288/ive-been-chipping-away-at-this-for-a-while-and

SKINS OVERLAY/OLHOS/CABELOS /MÓVEIS (ou seja não defaults):

Quando for baixar skins, olhos e você já tem a sua default e não quer mudar, baixa a versão CUSTOM, exemplo: https://lilith-sims.tumblr.com/post/151904708573/heeeey-i-made-this-skinblend-a-few-weeks-ago-it

Para cabelos, roupas, móveis, etc é só baixar normalmente, cuidando o post para ver se não é default.

CONVERSÃO DE OBJETOS, CABELOS, ETC DO THE SIMS 4 PARA O THE SIMS 2:

https://tvickiesims.tumblr.com/

https://www.tumblr.com/kestrelteens/754265693757849600/this-is-for-sims-2-whew-i-really-really-loved?source=share e https://www.tumblr.com/kestrelteens/tagged/4t2

https://www.tumblr.com/4t2clay (apenas cabelos)

DICA: pesquisar no tumblr a tag 4t2, exemplo > https://www.tumblr.com/tagged/4t2

https://www.tumblr.com/sims4t2bb/639693929792651264/sims-4t2-conversions-index-this-blog-provides-a?source=share (achei depois do vídeo um tumblr que coloca todas conversões de objetos dos conteúdos do 4 bem organizado)

LOTES:

https://www.tumblr.com/plumbtales (tem vários outros criadores, mas indico muito esse aqui!)

Como baixar LOTES? https://www.youtube.com/watch?v=UZsWiBLzLWc

Lotes com CC: https://www.youtube.com/watch?v=n8ZiAHKbaOM

CAMERA:

https://modthesims.info/d/97642

Caso queira checar esse mod de CAS, o Boring Bones mostrou como fazer: https://www.youtube.com/watch?v=1WhbIx0AR7I&t=287s

SOMBRAS:

https://www.tumblr.com/dreadpirate/180178957562/pineapple5050-post-processing-mod-snow-fix-this

CHEATS QUE MAIS USO:

Motherlode: Adiciona $50.000 em sua conta.

boolProp snapObjectsToGrid true/false: quando está em false (boolProp snapObjectsToGrid false) pode-se mover tranquilamente os objetos sem se preocupar com os quadriculados. Para desligar o cheat digite boolProp snapObjectsToGrid true/.

moveObjects on/off: remove a limitação de área afetada para todo o posicionamento de objetos no Modo Compra e no Modo Construção. Remove as limitações colocadas na Ferramenta Mão quando os objetos estão em uso ou são objetos que normalmente não podem ser movidos. Observe que usar esse truque permite que você exclua objetos que normalmente não podem ser excluídos, como Sims, a caixa de correio e a lata de lixo. Embora os Sims excluídos reapareçam quando você recarregar o lote, NÃO há como recuperar a caixa de correio e a lata de lixo, então tome cuidado!

boolProp allow45DegreeAngleOfRotation true/false: permite rotação de 45 graus em objetos. Use as teclas < e >para girar objetos diagonalmente.

Mais cheats: https://www.alalasims.com/the-sims-2/cheats

EXTRA: Luz Maxis Match que traz uma iluminação realista de fim de tarde, manhã, já que no The Sims 2 é apenas dia (claro) e escuro (noite).

https://dreadpirate.tumblr.com/post/175989937517/maxis-match-lighting-mod-at-last-i-finally

Se você precisa de um tutorial, assiste o da diva acottonsock: https://youtu.be/Y3TZV8FplcY?si=nH4EpoiCfVmMI678&t=3725. Está em inglês, mas dá para acompanhar, além disso, tem como ativar legendas. Eu realmente queria ter trazido esse, mas esqueci, lembrei muito tempo depois, desculpa :(

Caso seu The Sims 2 não abra, vá ná pasta Documentos>EA Games>The Sims 2 Legacy e exclua os arquivos 'Accessory.cache' e 'Groups.cache'. Não precisa fazer isso sempre apenas quando não abrir.

[krishna337]

HTML em Tag

The HTML <em> tag is used define emphasized text.It emphasizes the text inside the <em> tag by using verbal stress and the browser renders the text in italic. Syntax <em>Text Content...</em> Example <!DOCTYPE html> <html> <head> <title>HTML em Tag</title> </head> <body> <p>This is a normal paragraph</p> <p>This is an important paragraph with some…

[stoweboyd]

Tumblr Futures and the Newsletter Revolution

Tumblr could be a platform for newsletter writers and other creators

Photo by Patrick Fore on Unsplash

I've been using Tumblr fairly consistently for many years, here at stoweboyd.com and on other blogs, like workfutures.org. I think I moved to Tumblr sometime in 2007, importing materials I had managed previously on Typepad and Blogger. At any rate, I now have over 14,000 posts here, and (supposedly) 163,000+ followers.

I am dug in.

In recent years, with the rise of the newsletter revolution, I have tried many newsletter platforms, including Patreon, Medium, Revue, and Substack. At the present time I am publishing the Work Futures newsletter on Substack.

Substack is certainly the best of the various platforms I have tried. I want to like Medium, but they keep shifting their approach and plans, and have not been very fast at implementing various improvements they've discussed (such as importing subscriber lists). Substack simply works at what it aims to do. However, Substack lacks a feeling of community of the sort that Medium and Tumblr have.

I can envision a version of Tumblr that would include newsletter support: subscriber registration, subscription fees, emailing, stats, and so on. Much of this could build on the Tumblr follower model, extended to include subscribers.

I have no idea whether the Tumblr folks are intending anything of this sort. But why not?

Tumblr was acquired by Automattic -- the folks behind WordPress -- in August 2019, and has been letting Tumblr be Tumblr, aside from continuing the ban on adult content that Verizon imposed. There is work afoot to move Tumblr onto a WordPress backend, but no grand strategy has been disclosed about Tumblr and newsletters.

Automattic acquired Atavist in 2018, with the goal of integrating Atavist publishing model, including newsletters, into the company's existing LongReads product. LongReads is a reader-supported project to fund long format writing, and the feel is something like Medium: subscribers pay $5 per month to supporth the site.

In recent days, Facebook, Twitter, and LinkedIn have announced plans to get into newsletters, Twitter by acquisition of Revue. I am a heavy user of Twitter, and see that the Revue deal could work for them.

What I really want is a souped-up, newsletter-supporting Tumblr, where I can get the social media community of Tumblr with the addition of a newsletter community something like Substack, all in one package.

I hope they are working on it.

I forgot that I had written about this idea two years ago. See A New Direction For Tumblr:

For a few months, I have been advocating a major addition for Tumblr, something that might offer a new path for the more-or-less stagnant property: add the functionality to allow Tumblr 'creators’ to make money on the site. This would mean

Subscriptions for access to material behind a paywall (this would mean integration with Stripe or some other money platform)

Newsletter tools that integrate with Tumblr existing publishing workflow

Creation (or acquisition) or podcasting and video capabilities

Possible Medium-like publishing schemes so that creators can get paid for popular content.

Advertising opportunities based on tags?

I also happened upon this post by Richard MacManus from Sep 2019, How blogs, newsletters & Tumblr can fight back against social media - Cybercultural, in which he makes a similar argument:

In my view, there’s potential to build a significant new form of networking with blogs, Tumblr and email newsletters, this time built around cultural content.

The current wave of email newsletters proves there is demand for thoughtful media content, while Tumblr shows that this content can include more multimedia than we typically see in email newsletters. Naturally, multimedia is best viewed on the Web - not in inboxes. So I’m hoping Automattic can find a way to direct readers back to the Web, with the help of its latest acquisition.

[nirajmchauhan]

CSS: What's the difference between px, em & rem?

Photo by William Warby on Unsplash

Most of us grew up using px CSS unit. This code should be familiar to you width: 100px;. But in the past few years, I saw other units getting added to the CSS specs. So let's understand each of them.

Pixel(px)

So the word pixel doesn't mean a single pixel of your screen. This was shocking for me as well but it's true since 1996. Pixels are relative to the resolution of the canvas. By default, CSS defines the reference pixel which is usually a pixel on a 96 DPI display. Now we know that there are displays with different DPI like retina displays, in that case, the user agent rescales the pixel to match that of the display. So for retina displays, 1 CSS pixel is actually 2 Retina display pixels.

So with newer displays coming up, new CSS units had to be introduced.

em

Unlike pixels that are relative to displays, em's are relative to the parent elements font-size. So for eg: parent elements font-size is 16px then the child elements 1em value is 16px. Now, this sounds interesting but trust me, don't use the em unit. It becomes really messy if you start using it in a nested HTML structure. The following example demonstrates it very nicely.

See the Pen em font-size by Niraj (@nirajmchauhan) on CodePen.

rem

This is a better version of em, it works just like em, but instead of being parent element relative, rem's are always relative to the font-size of the root element i.e. HTML tag. So by default the HTML font-size is 16px so 1rem = 16px unless the HTML documents font-size is changed. Example:

See the Pen rem font-size by Niraj (@nirajmchauhan) on CodePen.

Conclusion:

First thing, try not to use em. Go with rem or px units. Now the place where rem becomes really useful is when it comes to responsiveness. So for eg on a bigger display if you change the default font-size of the browser, then the px unit will not scale, but if its rem then it would scale.

[polishcostumes]

I had a quick question: I'm wondering what is the difference between the Kontusz Sash polish nobility wore and the sashes you see in some traditional folk costumes, like from the Chełm region. Is there a specific name for the folk sash and where might I find more information about them? Also thank you for your blog, you're an amazing reference and a great help!

Hello! Firstly, sorry for my response coming late. I was very busy recently, but trying to catch up with the responses!Quick answer? Materials and patterns!Sashes of the nobility were really high in quality, woven from thin strands of silk and other expensive threads. They often had golden or silver strands incorporated into the motifs, and they were produced in certain manufactures by artisans, very often Armenian. The motifs woven on the sashes were sometimes coming from decorations from high-end western fashion. Those expensive sashes were inspired by Persian and Turkish outfits.## Here are examples of the nobility / kontusz sashes:_[18th-century Kontusz sash, Paschlis Jakubowicz's manufacture in Lipków](https://commons.wikimedia.org/wiki/File:Jakubowicz_manufacture_Kontusz_sash.jpg).__[Closeups of kontusz sashes from the collection of Museum in Płock](http://www.mdplock.pl/node/51).__[This is how they were often tied around the waist, exposing the decorative ends.](http://persjarnia.com/pl/katalog/zaglobas-sash/)__[Fragment of "Portrait of Kazimierz Antoni Krasicki", 1840s](https://commons.wikimedia.org/wiki/File:Anonymous_Kazimierz_Antoni_Krasicki.jpg)__[Fragment of "Portrait of Grzegorz Nowakowski", end of 18th century](http://cyfrowe.mnw.art.pl/dmuseion/docmetadata?id=42161&show_nav=true&full_screen=true#)_Sashes of the peasants were usually woven from much thicker threads like wool, and made locally on a loom, according to techniques and patterns passed down the generations. In some regions the name for them is _krajka_, but in most of the country they’re called just a _pas_ (belt). It differed between regions, but most often had simple striped patterns.## Here are examples of typical peasant sashes / belts:_[Woolen belt from Gąbin-Sanniki region, central Poland.](https://strojeludowe.net/#/gabinski/2/12) Old types of such belts in that region were 15cm wide and around 3 to 4 meters long.__[Woolen belt from village of Rudzienko near Kołbiel, east-central Poland](https://strojeludowe.net/#/kolbielski/2/15).__[Krajka from vicinity of Włodawa in eastern Poland.](https://www.muzeumlubelskie.pl/Zarys_etnograficzny_Lubelszczyzny_/Stroje_ludowe_Lubelszczyzny-1-418-73.html)__[More examples from Włodawa.](https://strojeludowe.net/#/podlaskiwlodawa/2/10)__[Green belt from Łęczyca, central Poland.](https://strojeludowe.net/#/leczycki/2/9)__[Belt from Łowicz, central Poland (modern reconstruction).](https://folkstar.pl/products,show,308,1,stroj-lowicki-ludowy-meski.html)__[Belt from region of Podlasie along the Bug River, north-eastern Poland.](http://patternsofeurope.pl/tradycyjne-wzornictwo-lubelszczyzny-dekoracje-strojow/)__[Belt from region of Świętokrzyskie (Holy Cross) in south-central Poland.](http://pik.kielce.pl/e-learning/stroje-ludowe-kielecczyzny/stroj-swietokrzyski.html)__[Belt pattern from vicinity of Jarosław in south-eastern Poland.](http://muzeum.przeworsk.pl/aktualnosci/ludowe-stroje-przeworskie-album-i-pliki-graficzne-do-pobrania/)__[Simple red belt worn in Kujawy, north-central Poland.](https://strojeludowe.net/#/kujawski/2/15)_Some belts / krajki were more decorative like those from Chełm, and there are some regional variants. Still, the belts were much more simple, and made only from local materials.This is how the peasant belts / krajki were usually made:[https://www.youtube.com/watch?v=3i1hwxQid9w](https://www.youtube.com/watch?v=3i1hwxQid9w)[https://www.youtube.com/watch?v=Davk1cf5Hhw](https://www.youtube.com/watch?v=Davk1cf5Hhw)Side note, among the regional costumes, the [Żywiec town costume](https://polishcostumes.tumblr.com/tagged/%C5%BCywiec) is a notable exception because the Żywiec man’s fashion is inspired directly by the historical clothing of szlachta. The Żywiec sashes are meant to resemble the historical kontusz sashes.

[nsfmc]

A checklist for computer science undergrads

influenced by john regehr's 'basic toolbox' post about this topic, i thought i would throw my hat into the ring given that my experiences have been different than john's and seem to be at odds with what i have observed from working with many competent developers.

As i was leaving grad school, a friend of mine suggested to me that a winning strategy in Industrial Design had been to pick some medium that you worked well in and focus on doing all your work with that. The rationale here was that starting anew each project with a new medium invariably impacted the execution of the final deliverable distracting your prof/critic/peers from the high-level feedback you actually wanted on your work, creative vision, etc.

The advice there is to focus less on the tool and more on using a tool efficiently to communicate your ideas. In most cases it does not matter what the tool is as long as you can deploy it to solve problems in your domain.

Much of the tooling that exists in CS is directed at very specific users: working programmers. using these tools correctly as an undergrad is aspirational, but often their execution is distorted in academic contexts.

Every lab or workplace should expect to bootstrap new hires on internal tooling/workflows and almost none of them should assume prior knowledge. Depending on the aims, the only hard requirement should be ability to program in a language or framework similar to the one being used.

Core skills

A single programming language

You do not need to be ultimately proficient in every language, you just need to be able to sketch out and implement a solution to most problems you encounter in one language you enjoy working in. Which language you pick does not matter. If you are in john's classes, however, you should probably ensure that you know two languages: a compiled/systems-ey one (rust, go, c, java, swift, clojure, etc) and a scripting language (python, ruby, javascript, clojurescript, elm, mathematica, anything goes here as long as it has a repl or runtime that you can use to hammer out solutions to problems).

If you're not one of john's students, typically the scripting language will suffice (although it is generally rare to finish a cs program being exposed to only one language).

s/Text Editor/Touch Typing/i

The advice to be familiar with a text editor is largely a request from others who expect you to competently pair-program with them at their pace. The point of knowing an editor is much the same as knowing at least one language passably: it should not be something that gets in your way.

More essential than being comfortable with a specific editor (it honestly does not matter which one as long as you like using it and you are productive with it) is being comfortable touch typing. In the event that slack or other IM platforms have not made you a better touch typist, it is well worth investing time if only so that the act of writing anything is no longer a major time hinderance.

At some point, you may find yourself bored or in need of procrastination and decide you want to customize your editor: that is a perfect time to try something like sublime or atom or vi or emacs.

rough shell experience

you should be able to navigate around a filesystem, make directories, read directory listings and read the cli help documentation for most commands.

you absolutely do not need to know the details of your shell's preferences around glob expansion or how to write legible shell scripts. you can learn that, but after a certain point, all the obscure functionality ends up beng more "dev-ops" style knowledge that rarely pays any dividends except when developing commercial developer-facing internal tooling.

incidentally, getting students past the hurdle of commandline BS is almost certainly a job of an advisor (or postdoc). Ignoring it helps nobody and if a research project's documentation (q.v. below) is poor or nonexistent, the PI only has themselves to blame for this ongoing time commitment.

reading documentation

this is probably the weakest skill i have seen from folks coming out of undergrad. nobody expects you to know all of a language, all of its quirks, etc etc. what you are expected to know is how to find the answer to any reasonable question around your language or toolchain of choice.

A useful skill: you should be able to, given a stylized block of shell commands, paste those into your terminal one-by-one in order to bootstrap some project i.e. ./configure && make && make test. nobody should expect that you understand autoconf unless your research project is specifically devoted to it in some obscure way (i'm sorry if this is the case).

Specifically, you do not need to know how to parse an excel-formatted csv, but you should know where to look (or be able to find a solution) in order to do that in a reasonable amount of time. You do not need to know what an ideal runtime serialization format is for your language, you only need to call back on the terms you learned in your cs classes: marshalling, serialization, persistence, writing data, etc. although it can be useful at the extremes, be skeptical of the amount and quality of programming language trivia you know offhand.

writing documentation

no, this is not technical writing. this simply means you should be able to write a plain text file for each project that outlines

how to build some program

what its implicit dependencies are

what its arguments are

what the exposed/public api is

aside from being useful to others, in roughly six weeks or half a semester, this will invariably be of use to future-you as well.

a good acid test here is pointing a friend to the project and asking if they can build it and understand how they might use it. at some point you will embed this knowledge into a Makefile, shell script, or some other dsl, but until then it is infinitely more useful to write down the steps.

html

unless this is your job (or you intend it to be) you only need to know how to make an academic-level webpage which requires only the most basic knowledge of semantic html: h1, h2, ul/ol li, p, a, img, pre, strong, em (optionally hr, dl dd & dt). avoid css. if anyone gives you shit, you can invoke "Default Systems" giving you a perfectly valid excuse to stop devoting any more attention to design after you have mastered those tags.

reproducing errors

it is unclear when you are an undergrad or novice if you have encountered a truly exceptional case or if you simply have no idea what you're doing. Make a habit of reproducing and then writing down steps to reproduce edge cases you encounter and share them with people you ask for help from.

above and beyond, if you can identify the specific step (or code or whatever) that you invoke that (seemingly) causes the error, you will have an easier time teasing apart the nature of bug as you are telling someone else about it.

the most basic of data visualization skills

all this means is that nobody is actually good at doing this and everyone thinks that two hours peeking at ggplot2 has made them wizards at communicating the complexity of some dataset or results. it hasn't.

in many cases it suffices to be able to graph something from mathematica, R, d3, mathplotlib, or google sheets / excel. again, nobody cares how you do it as long as you do it and it doesn't take you all day. if your lab or workplace has some in-house style for doing this, they will need to train you how to do that anyway.

nonlinear spider-sense

the single reason "big o" notation is taught in school is so that at some point you can look at a performance regression and say "ha, that almost looks like a parab—o.m.g." the ability to recognize code or performance that appears nonlinear (or pathologically exponential) is probably one of the core things that i think undergrads should try to hone because during almost no other time will you be asked repeatedly, and at length, to explain the space/time complexity of arbitrary blocks of code.

computers are fast enough that you can usually be blasé about performance but eventually you'll start looking. being able to recognize something that is accidentally quadratic is often the most practical day-to-day application of cs theory—hone this spider sense.

Nice to haves

Version Control

there is a large chasm between "git for one" and "using git as a team" and that harsh valley is almost certainly due to the large amount of human communication and coordination required to work on a project as a team. Most people stress learning git, but this is largely useless advice because most of git or hg's corner cases and weirdness only come up when you're trying to integrate your work successfully among your teammates. It is good advice to perhaps become vaguely competent using git or mercurial or rcs, that experience will almost certainly pale in comparison to the massive flail when you are trying to set up multiple worktrees to create integration branches that contain the contents of multiple prs (each likely with their own rebase/merge/squash quirks).

to that end, you should learn to, say, create a commit and push your work, but everything else beyond that is almost certainly guaranteed to be complicated by whatever your team's workflow is (github prs, phabricator, gerrit, etc). i have rarely met people outside of professional or open source contexts that are capable of producing sensible chained commits or sane pull requests, it is simply not a skill that is required outside of contributing to open source or working on a commercial application. When people ask for git experience they secretly crave this flavor of professionalism that it took months to acquire at each of their prior jobs or internships.

A Presentation Tool

the baseline here is very low, you only need to be able to make a presentation and in all likelihood if you are still an undergrad, you easily have ten-plus years of doing this already. worry about fonts/design/transitions/etc once your content is solid.

most people produce terrible presentations making the needed baseline here quite low—it is more important that you know how to practice giving a presentation than it is to actually create the slides for it.

debugger knowledge

i have met many successful professional working programmers that have little to no idea how their language's debugging tools work. if you are a gdb wizard this sounds shocking on its face but lots of developers make do just fine without them. This is not to say that you should be willfully ignorant of debuggers or eschew them (especially if this is part of your curriculum), but nobody should look down on you if you learn (or are taught this) On The Job.

many of these tools are technically robust but have a ui only moderately less hostile than an opaque box of loose razorblades and chocolates. much like git, most developers internalize some form of stockholm affection for these tools despite their poor design, nonexistent editor integration, and often incomplete terminal support.

you should understand roughly what a debugger is and what it can (and can't) do, but it's almost certain that you won't need to have mastered debugger internals straight out of college.

build systems

this is honestly a "top of maslow" need. This is great knowledge if you are planning to distribute code or need it to build dependably/reliably on others' computers, it is absolutely inessential for an undergrad to understand to do this level of orchestration except as documentation for others to evaluate that your project actually builds etc etc. if your advisor or boss asks you to learn something like make or whatever, then by all means.

You should know what a make tool is for and when it is necessary, but you should not expect that to apply to the lion's share of work you do in school.

working for a period of time before asking for help

although this should be a core skill many adults are incapable of doing this effectively. there is a tradeoff between "i'm learning" and "i'm being unproductive." In an academic lab, arguably much of your experience will appear to be some quantum state that simultaneously inhabits both extremes but your goal should be attempting to independently arrive at a solution and after some time cut-off (which you should negotiate with your advisor/postdoc/pi/whatever) you should say "i tried $A, $B, and $C to accomplish $GOAL and was unable to make any progress because $ERR_A, $ERR_B, and $ERR_C."

even the act of noting down "what i am trying to accomplish, how i tried, what went wrong" may in itself lead you to a correct solution, but without having done that due dilligence and outlined those aspects, it will be difficult to receive good feedback from somebody that is trying to help you.

unit/integrated/etc testing

if you find that something like TDD is useful for you as a productivity or refactoring tool, keep doing that! most working software people cannot even agree on what the point of testing is, so it feels unfair to burden undergrads with this. in a professional context, you will be in a codebase with some established testing norms, you need only mimic those until you have determined what works for you.

there are lots of sane and sensible resources for writing tests or thinking about tests. understand that everyone does testing slightly differently so your best bet will be to figure out how testing plays a part wherever you go. in most cases, that codebase will have a specific incantation to invoke tests, your best bet is to ask how they do things there are just go from there if the setup is not obvious.

understanding scope

most academic projects are poorly managed because they have inconsistent pressure to be profitable beyond whatever funding inspired them. simultaneously, many academic advisors are not trained well to manage or lead a team (remember, most were hired to write grants and produce research papers (or possibly to teach)). management is something an advisor is literally picking up "on the job".

If you are unsure what exactly you are supposed to do, you should clarify as soon as possible what deliverable is expected and when it is due. This seems obvious, but because communication is complicated you may end up assuming you need to, for instance, resolve outstanding cli argument parsing bugs rather than only needing to add support for a new one. Understanding the scope of a project you've been assigned prevents you from doing redundant work or opening prs that will never get merged.

language idioms

If you are cozy with a programming language, the natural evolution here is to begin learning what idiomatic programming is like for it: what are common libraries, do people tend to program it functionally or imperatively, for or map?, what patterns are awkward or hard to read, what are common tools in its toolchain, how do people use it to write web services, how do people use it to avoid shell scripting, what are its peformance pathologies, etc. this is the extension to knowing how to read the documentation: it is developing intuition about the language to avoid doing counterproductive work in the future.

Many developers learn one language and become fluent in its quirks then proceed to apply those to every language they see later on. if you encounter this as a novice, it may appear that they are simply Better Programmers and not, instead, people who are speaking a pidgin-python with a heavy haskell accent.

To recap

It is something of a mistake to hope that a cs student will have the gradually developed and refined skills of a professional tradesperson. Graduating cs students often do not have strong professional software development experience (this is what internships are meant to accomplish) but are good at thinking about design/architecture. if, at the very minimum, as an undergrad you can churn out some ruby and have the runtime execute it, you're usually in great shape.

most cs programs do not train students to develop tightly crafted applications with industry-tested documentation/syntax/structure/workflows etc. bootcamps, however, do stress this sort of thing, which causes a confusing periodic wave of "college is dead, long live bootcamps."

when looking at job descriptions or other checklists, it's useful to try to gaze back at the abyss and ask "why was this listed here?"

John's research is compiler-focused, deals with undefined behavior, and often invokes llvm, c, and other "low level" toolchains. a strong undergrad cs student will be able to intern with john productively because the core of his research focus is mostly general to computer science: correctness, compiler behavior, etc. someone with deep knowledge of C, llvm, compiler design/internals, etc is almost certainly in a position to become one of his graduate students or postdocs. I think john's list is interesting, but i think it emphasizes details that are often foreign to developers at all skill levels.

finally this list is biased itself, so take it with a grain of salt: all my work experience is in design and frontend/backend web development and the skills listed here represent the qualities i've observed from successful interns and developers i have interviewed and worked with in the past ~ eight years. my experience is clearly n=1, but among the things i've noticed is that it's easy to get people to learn git, but it's hard to get somebody to internalize recursion, nonlinear growth, or canonical architecture patterns within the same time period. i'm not saying it's impossible, but if you're a cs student, this is 100% what the point of most cs programs is.

[fuckyeahscandalband]

SCANDAL's RINA; "It's me RINA" Style Book Translations Part 3 of 5 - FASHION

Fashion = Things that make the day's mood. RINA, with her favourite vintage theme as base, meets with a different side of herself each and every day♥

"When putting together my favourite style, I'm happy if it's something simple. When RINA wakes up first thing in the morning, I'll have an image of the day in mind, and work towards creating that mood. Fashion is something that's able to change the people you meet, the places you go to, and the way you spend the entire day. That is why, I, RINA, think that fashion = things that make the day's mood."

In this section, Rina shares many fashion co-ordinates and vintage items, in pictures that can also be seen on SCANDAL's blog, or her own personal Twitter or Instagram account. Many reflect her liking for girlier styles, but she also explores casual, retro or more rocker-type outfits. All of her outfits use vintage clothing as a basis.

Rina also introduces her beloved beauty items! Here are some of the items that she uses:

Shampoo: BOTANIST Botanical Shampoo and Treatment. She also reveals that she hits the salon twice a month to do regular hair treatments.

Hair Oil: L'occitane. Rina adores its frangrance and oily texture. After getting out of the bathroom and brushing her hair, she'll apply some to the ends of her hair.

Hair Straightener: Bioprogramming's HAIRBEAURON. She uses this for her fringe everyday.

Hair Dryer: Panasonic's EH-NA93. She brings this along with her on tours, be it within or outside of the country.

Throat: Organic Manuka Honey SnapPak Sachets & lozenges, HICEE 1000. For the Manuka sachets, she makes sure to drink some when her throat hurts when on tours. For the Manuka candies and lozenges, she'll pop one right before each live. For the HICEE 1000 vitamins, she's been taking one every night before sleeping since 5 years ago.

Body Milk: SABON's silky body milk in Lavender and Vanilla. Rina enjoys using products by SABON for her body care, because of its moisturising and wonderful smell that helps her relax.

Skin: Various products by La Roche-Posay. As recommended by her dermatologist several years ago, she's been a fan of La Roche-Posay's skincare products.

Eyecream: Chanel's LA CRÈME YEUX. She especially uses it a few days before any shoot, and is her special eye skin care during more tiring times like these.

Facemask: Lu Lu Lun. When on tour and if she has the time, Rina will use Lu Lu Lun's blue face mask, which has high moisture in its face masks.

Eyeshadow: Various colours by ADDICTION. Rina also has dark colours, which are useful for lives and performances, when she wants a change of mood.

Eyeliner: Loveliner's liquid eyeliner in dark brown. She also uses this during lives, as the colour bounces off under the light easily.

Blusher: ADDICTION's Shanghai Breakfast and Alice colours. As her hair colour usually more bent towards a reddish tone, she uses a lot more reddish colours for her make-up.

Lip: RMK's Irresistable Glow Lips in EX-08, Revlon's Matt Balm in 45. Rina makes use of both in this order, on her off-days.

Translations & photos by fyscandalband. To purchase, click HERE. For my "It's me RINA" tag, click HERE. As I’ll only translate what piques my interest, this is only a part of the interview and not a full translation. More to come.

[infiniteundo]

Software As Narrative Parts 1-8 Collected

I was asked by Twitter to switch to long form writing about testing, QA and risk. Here are the early raw results of my return to blogging about… all of those things Please note that part 7, the [further reading page.](http://infiniteundo.com/post/158412712773/further-reading-s-as-n-7n "The Further Reading page is constantly being updated with new resources!") is not included here as that is a living document.

Table of Contents

Part One: in which the map disturbingly turns out to be the territory

Part Two: in which robust partition tolerance is found to be desirable but impossible

Part Three: in which someone got punched in the face

Part Four: in which the significance of software as narrative is expounded upon

Part Five: a brief examination of the social forcing functions exposed by narrative tactics

Part Six: in which a fictional old-timer relates tales of the SDLC

Part Seven: list of further reading materials

Part Eight: in which the hidden art of de-noising is shewn for the non-initiate

Part One

> Any software system begins as a shared narrative about a problem and > the people who come together around solving that problem.

If you don't accept the above proposition completely then nothing I have to say about software is going to work for you.

Chthulhucene Devops: staying with the trouble as a service

This is and always has been the core proposition of my "way of Devops." Which I am now finally able to articulate and which I differentiate from other devops as Chtulhucene Devops, so as to acknowledge that it is not "mine" in any sense except as far as I know I am its sole practicing engineer. Designers and executives and other leaders may practice it --- but developers mostly have a hard time with the tolerance for chaos required for what Donna Haraway has so insightfully now labeled: "staying with the trouble."

Software is narrative

> The problem with intelligent communication is the illusion that it > has taken place. > > -- GB Shaw

Suspend your disbelief and just run with this for one minute if you will: commercial software is a narrative about a problem and the community of people who come together around said problem. Note that I haven't said anything about money or value streams yet. That's the beauty of this approach: you start at the highest-possible view of the project: the gods-eye view. This is what the narrative approach can deliver to you, the confused but eager software hacker-er.

You see, a big problem in software -- the main problem -- is that you wake up one morning and find that you've spent 3 months building the wrong thing. It seemed like the right thing 3 months ago, communications got dropped, mistakes were made, it's wrong now. This can happen so easily with software.

The problem of what was it even supposed to do in the first place

In order to not build the wrong thing we must know with clarity what we are meant to be building. It sounds like a tautology and if we were talking about any medium but the digital medium it would be a tautology. But as all software engineers immediately come to learn, there is a Lovecraftian, Non-Newtonian gulf between "what we build" and "what we were meant to be building."

"Know what is meant to be happening not just what is happening" is anything but a tautology in software. It is a yawning conceptual gulf that can swallow projects whole.

How do you know what is meant to be happening?

As people we have something called an inner narrative that we compare to the external happenings in the world and that's how we do sense-making. The thing is that the "external happenings" of the world aren't external at all. Events in the world around us impinge on and irrevocably merge with our "inner" narratives.

The world is made of stories

Stories are how we do sense-making. Stories are literally the tool that allowed us to come down from the trees. We couldn't master fire until we could fashion a story about how to master fire.

But with fire there was a physical thing to point to: the thing that is on fire. Get that thing. Such were our stories. For almost our entire time on earth as a species, stories were basically: there is thing, do something with thing.

But now we can't use that narrative any more even. Because with the digital domain there is no "raw material" that we start with to create products. That this is the case causes a lot of mis-spent Web budgets, because it is counterintuitive so people tend to budget in spite of it not in alignment with the reality that Web products all begin as stories and some are less fictional than others.

There is no thing

> A monk asked Joshu, a Chinese Zen master: Has a dog Buddha-nature or > not?' > > Joshu answered:Mu.'

In software there is no "thing" that you can point at. In order to point at a "thing" in software you have to construct the thing, starting with the environment in which the thing is going to exist.

You always have to design both "the product" your customers want and "the environment" in which your product will run in production. Thus any software product begins with two obvious categories of "work to be done." People ignore this because it seems counterintuitive.

Now you have two problems

> A programmer has a problem and says I know I'll use Perl. > > Now they have 2 problems.

This is a class of Boundary Problem -- you always have to design the environment your software product "lives" in, no matter how hard you try to isolate your project from the vagaries of its environment.

This observation generalizes and goes back at least to Wittgenstein who said of Boundary Conditions in general:

> Can't we imagine a rule determining the application of a rule, and a > doubt which [it] removes — and so on?

Further reading

For further reading on this and related chtulhucene devops topics, please visit the further reading page.

Part Two

No you have n+1 problems

The old joke goes like this:

> A programmer has a problem and says I know I'll use Perl. > > Now they have 2 problems.

It's ha-ha only serious humor or as I prefer to call it: you-have-to-laugh-because-you-can't-cry humor. I may have learned this phrase from my dad, who was a journalist.

Solving a problem with a Web service (or a device or an appliance or a mobile app that depends on Web services -- to me it is the same thing!) is not just finding the solution but keeping the solution running in production forever after. That you have to be responsible for the product in the long term is something a lot of people overlook. In the early days of software "keeping it running" was minimized under the label "maintenance" or "system operations" making it sound like a negligibly important background activity.

Don't bet against the CAP theorem

It turns out that keeping Web services running is really hard. That's why so many historical Web sites even though they were super cool are no longer around: it's really expensive to pay people to run sites. And it turns out people don't like running sites no one uses. This is new information as of about 2008 or so -- before that everyone assumed the opposite was true.

The crowd that realized they were wrong and copped to it coined the word "devops" to describe their insight. Devops just means that you try to establish common ground within the company, in response to any problem you establish common ground and work together toward a commonly-known compromise goal of solving the problem. It's drawn from Theory Of Constraints and other stuff that if you are reading this series of posts still, I probably don't have to explain to you!

You can't sacrifice Consistency

It turns out people really care about their data. You can't build a distributed system that is resistant against partitions. You can't build a site that's up all the time. But you can damn well ensure that if the user saved data with you and you told them you got it, that you definitely really still got it.

The value of data integrity to users is often overlooked. Doubters would do well to remember Ma.gn.ol.ia.

So given that these "ops" exist…

Ops came to prominence in the mid-to-late 2000s as Web 2.0 apps like Gmail and Google Maps exploded in popularity. Not to mention a stupid service called twittr that was started around then too that one caused all kinds of trouble.

The thing is that you can scale hardware and you can scale software but people can't be cloned nor can more people be trained to do hard specialized nerd labor like Ops.

The moral of the story so far

So as a person who is interested in making a thing that will work on the internet, you need to learn about Ops. Now. And you need to learn as much as you can. Because real ops people cost a lot of money and for the most part you can bet you will never even work with one. They are that rare because the Internet of the 2000s got HUGE that fast. It really did. I was there. Ask me.

So dev and ops must find common ground. There are not enough ops any more to run the web and there never will be again because the web got so big so fast and keeps expanding at about the same rate as fuck I have no idea nothing I have ever seen. Like a rainbow kaboom this web we built kind of mostly on accident if history be known.

Oh.

There's that troublesome idea again. History.

Narrrative. Let's get back to talking about how to leverage the insight that software is at its heart a narrative.

Part Three

For the sake of argument

For the sake of argument let's say that I am right and that all software is at its heart a narrative?

Wait I take that back. I can prove I'm right. I don't need you to suspend your disbelief for this to make sense. Although in the future if you keep reading I will teach you how selectively suspending your disbelief (and that of others) can be advantageous.

For the sake of argument JUST LISTEN TO ME HERE

If software were in fact composed of stories that are shared between people, then we could easily decompose software into stories and indeed the software industry fairly blossoms with different options for doing so. Story-driven-development and ideation run amok in silicon alley, to mostly good effect!

If software were narrative then it would be possible to get just the idea of software funded and valued as if it were a real existing software (whatever that means do you start to grok me yet?)

We all know things get funded that don't get built

Things get funded because someone likes the story. Things don't get built for all kinds of Reasons. That a software thing was not built at all does not in any way imply that no work went into trying to build the thing. A common tragedy in the programming profession is that we build a word processor in place of what was actually needed I am not entirely making that up.

That software can be almost built for years but never actually work supports my point. If effort went into the software and the software never worked (to take an extreme case for the sake of argument.)

If that were the case, what do we have, the non-working stuff of the project? Well literally a developer will tell you "we have what's in Git history." Literally we have a story.

Git stores histories which are stories which is what narrative means. Game set match.

Part Four

Software is narrative: so what this is old news.

Great question!

Narratives have certain essential characteristics. All software methodologies to date have failed to reduce software to any certain set of essential characteristics.

To view software as narrative is an application of the Theory of Constraints: by applying the constraint that software must at some level be viewed / viewable as narrative, we reduce all software to simple essential characterstics.

Further we advantage ourselves of the multitudinous perspectives from 3 million years of proto/human evolution that led to having minds that can carry complex things like stories, even stories about how processors are supposed to interact with strange fictional beings we tell each other are called "the Integers."

If you accept that the digital realm is narrative first

If you accept that the digital realm is narrative first then you realize quickly that you can still capitalize on the True Promise of the Web.

This is quite an exciting insight since it means there are numerous ways of getting mad paid on the Web, that have been overlooked because no one was looking to monetize narratives-as-such. But narratives certainly exist as such. And I have now rationalized their value.

In fact I have state and will continue to state that all my success, my career, my talks, Etsy, Barnes and Noble iOs automated builds, all my stuff, it worked (and some of it continues to work in production to this day, amazingly enough!) because I always subscribed to this vision of software as narrative.

This insight is the thing that makes my solutions stand up where others' don't.

It has taken me many years and much talking in private to more people than I can thank (although obviously MY WIFE deserves a big round of applause) to arrive at a place in my life where I can explain how I did what I did at each of those famously successful job sites.

Because I always felt I was carrying out a repeatable process and I was right. It just took time and self-reflection to arrive at a place where I could start to attach allegories and case studies to these: the central insights of my career.

Part Five

How do you use software to control the narrative?

You should be so lucky as to have a month of vacation saved up and a ticket you can buy to some isolated terrain where you can meditate upon this:

> Given that software products are composed of competing/interacting > narratives, how do I use software to control the narrative?

Because code in a very fundamental way determines the laws of what is and is not possible within a network of people thinking about the same problem.

The insight that code is narrative enables new ways of thinking. If you can go away and meditate on how to monetize and / or make benefit to your fellow beings with this insight you should do that. I sort of already I have I guess. It was cool. You'll like it. Great excuse to take some "me time" and come back with a new startup idea.

Part Six

The Software Development Life Cycle reconsidered as a story cycle

A trilogy. Part the first:

First of all young'n, have ye never yeven heared of ye olde SDLC?

Why then read ye of the s, the d the l and the c fore I whack ye with my specially reserved get-off-my-lawnHammer-of-doom+4!

For I have been a hax0r yes! A hax0r of yore, in the days when bases were belong to us and yet before. When the bases belonged to no one yet.

I am long in tooth and hot of air and I speak for the cats of the internet. And the lolcats say: go forth and do not break the Web. And the cats say: we serve the will of Sir Tim Berners-Lee: break not the Web for it is already yet just a little bit broken. Let none seek to break it further and that's QA or something. Thanks goodbye.

Part Eight

Fix All Errors And Warnings: A Narrative Perspective On The ROI Of De-Noising Logs

Before its use in computing the word log referred to a journal kept by a human: a log is a record of events in the real world. Logs recount histories and by doing so logs participate in the multiple narratives of success and failure in intractably complex sociotechnical organizations.

Logs Contain Historical Evidence

On the Web when something fails the server and application logs are the source of truth about the chain of events. Logs are the primary evidence that we use to reconstruct the chain of failure and then present a new narrative where the system works again.

Logs Contain A Lot Of Signal

The actionability of error messages is of direct business value. The faster a Web product can recover from an incident (MTTR) the less impact that incident is likely to cause. In the best case incidents are detected at the precursor stage and no production impact whatever takes place. Such is the power of high-signal logs.

Now add noise

Now to this high ROI first-responder log capability, add noise. Why?

Right.

There is no value in allowing noise in logs. Noise here can only impact the hard-won ROI of actionable service logs.

Don't add noise to logs, it screws up the narrative

At best a collection of service logs during an incident (and here I include RRD services and StatsD, Splunk --- they are all ways of logging) is a trigger for that eureka moment where an impending incident becomes a simple matter of fixing misconfiguration.

Ignoreable Errors Are A Cargo Cult

There is no logical reason to allow errors in your logs that you can safely ignore. Just filter the spurious errors using grep -v it's that easy. Kill the noise.

[vishers]

Let’s Review Some Bash: A Command to Execute Curl Based on MySQL Output

████████: @timvisher: can you give this a bash code review for me?

bengarvey: @████████ last time I asked Tim Visher to review my bash script I rewrote it in a different language

In this (potential) series I take bash code that comes across my inbox and review it for all the world to see. It's an attempt to sharpen my own scripting skills as well as potentially be a source for others to get better at scripting themselves. I still consider myself an amateur scripter and my opinions are my own. If you really want to learn from the best, talk to Greg.

In this edition of Let's Review Some Bash we're going to transform

#!/bin/bash mysql frobnastic -N -B -e 'select type from frobnastic;' | while read -r line ; do curl 'https://frobnastic/types/'$line -H | jq . > 'frobnsatic-responses/'$line'.json' done

into

#!/usr/bin/env bash ########################################################################## ### Save pretty printed frobnastic type responses for all frobnastic types ### in the DB ########################################################################## mkdir -p 'frobnastic responses' && mysql --skip-column-names \ --batch \ --execute='select type from frobnastic;' \ frobnastic | while read -r frobnastic_type; do curl --silent --fail --show-error \ "https://frobnastic/types/${frobnastic_type}" | jq '.' > "frobnastic responses/${frobnastic_type}.json" done

First thoughts:

I don't love using shorthand flags in my scripts as I find they're harder to remember than the long versions

It's odd that we're putting the database name at the beginning of command rather than the end as the manual states we should although I believe that it works

We're using /bin/bash rather than /usr/bin/env bash

We have a dangling -H on the curl command. I'm not even sure what happens in curl when you do that

We're not quoting

We're not wrapping at our control operators

jq's print filter is bare

We're not ensuring our output directory exists

Initially let's just cleanup that Sha-Bang, take care of wrapping at control operators, quote our expansions, and delete that dangling -H and see where that leaves us.

#!/usr/bin/env bash mysql frobnastic -N -B -e 'select type from frobnastic;' | while read -r line do curl 'https://frobnastic/types/'"${line}" | jq '.' > 'frobnsatic-responses/'"${line}"'.json' done

Already I think it reads a lot better. We're more portable because we're using /usr/bin/env to execute bash. Our lines aren't quite so long so this command will be easy to review in any context. Pipes have become clearer.

I go back and forth on how to include expansions in strings. Between the following I'm not sure what's clearest.

x=foo echo 'This is what x='"$x" echo "This is what x=${x}" printf 'This is what x=%s\n' "$x" printf 'This is what x=%x\n' "${x}"

Generally speaking I prefer to use the least featureful context for any given job in any given language. For instance, in Ruby if I don't require String Interpolation then I stick with single quotes. If at some point in the future I do require it then at that point I shift up to double quotes. I find this is a subtle signal to the future readers of what to expect and I like features like this in the languages I use.

In the case of bash, quoting is quite a topic in its own right and it's all because of the features available in each quoting context. If I had to try to put my style to words it would be something like "Prefer $x if the added clarity of ${x} isn't required and you don't require the additional features of ({x}". So you'll almost never find ="){x}"= anywhere in my code but you'll often find "Foo bar ${x}" there because I find that when I'm using something more like ruby's string interpolation the additional curlys add to the clarity that an expansion is happening. Also in very rare cases they help bash figure out that it actually should expand something when there's ambiguity in the parser.

In general I also prefer to minimize the number of quoting context types in a given word. While

[[ 'f'"o"$'o'$"b"$'e'"a"'r' == foobear ]]; echo $? # => 0

it's kind of a spacebrained way of writing

[[ foobear == foobear ]]; echo $? # => 0

I say all this because the next transformation I'd like to make to the command would be to cleanup the quoting contexts just a little.

#!/usr/bin/env bash mkdir -p 'frobnastic responses' && mysql frobnastic -N -B -e 'select type from frobnastic;' | while read -r line do curl "https://frobnastic/types/${line}" | jq '.' > "frobnsatic responses/${line}.json" done

Now, we're ensuring that our responses directory exists which saves us from having to do it ourselves. We also won't bother making any curl requests if we can't make the responses directory. And each of our words looks like a word rather than a jamming together of quoting contexts.

This isn't always possible. Sometimes you need to use an expansion in a word that must contain characters that would be expanded and so you're left with jamming together contexts. In particular embedding expansions in jq filters can lead to some wildly nasty looking contexts like:

#!/usr/bin/env bash jq 'select((.when | debug) ["DEBUG:","2020-04-13T14:07:14+0000"] # ["DEBUG:","2020-04-13T14:07:04+0000"] # "2020-04-13T14:07:04+0000" # ["DEBUG:","2020-04-13T14:07:14+0000"] # ["DEBUG:","2020-04-13T14:07:14+0000"] # ["DEBUG:","2020-04-13T14:07:14+0000"] # ["DEBUG:","2020-04-13T14:07:24+0000"]

In this example we've got some embedded command substitutions and that would really mess with our jq mojo. So we have the wildly awkward "'"$(…)"'" sequence which adds a literal " to the initial literal context, closes the literal context with ', opens an expansion context with ", uses a command substitution with $(…), and then closes the expansion context again, opens a a literal context, and inserts a literal " there.

Finally, let's expand some of the shorthand options, rename variable, add some documentation, and call it a day.

#!/usr/bin/env bash ########################################################################## ### Save pretty printed frobnastic type responses for all frobnastic types ### in the DB ########################################################################## mkdir -p 'frobnastic responses' && mysql --skip-column-names \ --batch \ --execute='select type from frobnastic;' \ frobnastic | while read -r frobnastic_type do curl --silent --fail --show-error \ "https://frobnastic/types/${frobnastic_type}" | jq '.' > "frobnastic responses/${frobnastic_type}.json" done

Et voila. Cheerio.

[oxyiorg]

Germany Map Before World War 2

Germany Map Before World War 2

[mwp_html tag=”img” src=”https://oxyi.org/wp-content/uploads/2019/08/map-of-germany-before-and-after-wwii-europe-maps-map-layout-regarding-germany-map-before-world-war-2.jpg” alt=”Map Of Germany Before And After Wwii. | Europe Maps | Map Layout regarding Germany Map Before World War 2″ width=”800″]

Map Of Germany Before And After Wwii. | Europe Maps | Map Layout regarding Germany Map Before World…

[annaxkeating]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

from Digital https://unbounce.com/online-marketing/why-marketers-should-implement-amp/ via http://www.rssmix.com/

[josephkchoi]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse) published first on https://nickpontemrktg.wordpress.com/

[jjonassevilla]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

from Marketing https://unbounce.com/online-marketing/why-marketers-should-implement-amp/ via http://www.rssmix.com/

[itsjessicaisreal]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

from Marketing https://unbounce.com/online-marketing/why-marketers-should-implement-amp/ via http://www.rssmix.com/

[kennethmontiveros]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse) published first on http://nickpontemktg.blogspot.com/

[samanthasmeyers]

Almost 60% of marketers haven’t implemented AMP, see why (and why it’s no excuse)

When it comes to page speed, a few seconds of slowdown can cost you. Slow load times cripple conversion rates, raise the price you pay for ad impressions, and even drive qualified traffic to your competitors.

All this being true, Accelerated Mobile Pages (AMP) would seem like the hail mary pass that marketers have been waiting for. Essentially, AMP is a Google-backed framework for creating web pages that deliver near-instant load times, even on mobile. I say “near-instant” here, but I like how the AMP Project itself puts it: AMP pages are “so fast they appear to load instantly.”

What does AMP mean for marketers? Faster delivery of your content, for one thing. The end of waiting altogether, maybe. Ultimately, AMP can result in a significant uptick in traffic and improved conversion rates overall.

So, naturally, every marketer is planning to adopt it in 2019, right? Right!?

*record scratch*

Marketers have been slow to adopt AMP for a variety of reasons (via Unbounce’s 2019 Page Speed Report).

Wait, wait, I can explain. As part of our 2019 Page Speed Report, we asked marketers if they planned to implement AMP in the near future. 57% of them told us they have no plans to implement it, while 23% are still considering it.

Those who haven’t adopted the framework have a range of reasons why, but they fall into three broad categories:

AMP requires a significant investment of developer resources.

AMP is poorly understood (or perhaps poorly messaged).

Google’s past behavior has made some people wary of AMP.

I’ll explore these reasons in further detail below. For now, it’s worth saying that each has some validity. But I don’t think any of them—alone or together—should be your excuse not to implement AMP for your marketing campaigns.

In the long run, businesses who overcome these objections will be better positioned than those who don’t, despite perceived drawbacks. As I wrote elsewhere, “Turbo-charged landing pages result in more traffic and higher engagement, boosting conversions and helping PPC campaigns win increased ad impressions for less.” The AMP framework helps you achieve this kind of performance, even on a smartphone.

Want more insights about page speed? You can explore all the findings in the complete 2019 Page Speed Report for Marketers here. Access is free and ungated, so take a look.

Reason 1: Limited development resources

A significant hurdle that marketers face when it comes to adding AMP to their site has to do with technical resourcing. Four of the answers to our survey question touched on this problem:

Developers are not experienced with coding for AMP (12% of respondents)

No developer capacity to implement it (32% of respondents)

Too time-consuming to implement it (12% of respondents)

Validation issues with AMP pages we did create (2% of respondents)

It’s no secret that AMP comes with a steep-ish learning curve.

By using a restricted version of HTML and a custom JavaScript library, the framework ensures an optimized (read: fast-loading!) experience. Using Google’s AMP Cache (a content delivery network that stores your page on Google’s servers) further accelerates your pages.

But it also requires your developers to dedicate time to learning and mastering AMP-HTML and the AMP JavaScript library. And since Google’s AMP Cache requires validation once you’ve built an AMP page, there’s really no “good enough” moment here. Either your page works and goes live, or it doesn’t and you need to find your error. Who feels motivated to learn under those conditions?

AMP validation in action—or should I write, “inaction”? (via The AMP Project).

By its very nature, the limitations of AMP also demand a certain, let’s say, technical dexterity. Because bloated scripts tend to be a major contributor to slowdown, AMP’s JavaScript library puts the brakes on the third-party scripting that people have gotten used to using. (And AMP HTML comes with its own quirks.) Working within these constraints can often produce innovation, but it’s also a source of frustration for many who just wanna get stuff done.

Finally, poor analytics has been significant speed bumps on the road to AMP adoption. Tracking and analyzing visitor behavior is an integral part of running an online marketing campaign, but early in its life, AMP asked us to go blind. No thank you.

Why time and dev work are no excuse…

First, let’s be real: the AMP framework is a set of restrictions. That’s the point. So wishing for an AMP without any limitations at all doesn’t make sense.

In addition, many of the difficulties that plagued developers in the early years of AMP are no longer an issue. Tracking, for instance, has improved dramatically since AMP launched in 2015. Today, by using the AMP Analytics tag, you can isolate and analyze AMP traffic in Google Analytics. Though it can’t yet do everything that standard tracking can, it will collect data about users, pages, browsing, and (most significantly) events. As Search Engine Journal points out, “for most content marketers, that’s sufficient.” Not a ringing endorsement, sure, but tracking is now good enough for most marketing purposes.

As AMP development has continued, scripting has also become more robust, and the options available have expanded. Unfortunately, many people rely on scripts from third parties for tracking and integrations, but a lot of companies have been slow to deliver AMP-compatible versions. As adoption has increased, however, so too has the pressure on these companies to deliver.

That said, some of what AMP asks us to leave behind is also inessential. Pages clogged by unoptimized script may soon be looked upon we look at the tailfins on the back of a 50’s Cadillac. (Or, hey, remember the heady days when every site seemed to require Macromedia Flash? When it comes to the web, more isn’t always better.)

Reason 2: Some marketers really don’t get this whole AMP thing

Despite having a mouth to Google’s megaphone, the AMP Project has struggled to be heard beyond web development or publishing circles. When we asked marketers in The Page Speed Report, we discovered the following:

There’s a lot of misunderstanding when it comes to AMP (via Unbounce’s 2019 Page Speed Report).

While 54% of the digital marketers said they have some understanding of AMP, the rest assuredly did not. A quarter of ’em hadn’t even heard of Accelerated Mobile Pages before taking our survey.

Why misunderstanding is no excuse…

First, AMP is hardly floundering, despite the fact that you may not have heard about it. It has the combined might of Google, Pinterest, Twitter, WordPress, and Bing backing it. And AMP already covers more than 31 million domains serving billions of AMP pages. If you browse the web on your smartphone, in other words, chances are very strong you’ve visited an AMP page.

AMP pages appear in the search results with a lightning bolt icon.

Second, if you hadn’t heard of AMP until you read this article, no worries—because now you have. That gives you an advantage over the 24% of marketers who’re still in the dark. It’s always best to think competitively about page speed. Knowing about AMP (and implementing it) can put you out in front of your competitors by dramatically improving your load times.

EDITOR’S NOTE. There’s a lot of misinformation or misunderstanding out there about AMP. You can read more about AMP and its myths in this blog post from Unbounce’s Larissa Hildebrandt.

Reason 3: Google is “evil” now

Even before they stripped the “don’t be evil” clause from their official code of conduct last year, Google earned a reputation for shady doings.

With the launch of the AMP Project in October of 2015, though, they stirred up a controversy that they didn’t seem to anticipate. Critics were quick to argue that AMP represents yet another move to lock down the web, gallingly disguised as an open-source project.

Many of these accusations point to the Google AMP Cache, which speeds up delivery of content by storing your pages on Google’s servers. AMP doesn’t actually require using Google’s cache—people can create their own—but this tends to be how it’s done. In most cases, the content lives with Google, and a searcher may never touch your actual website. As Daniel Miessler puts it, this is potentially “poisonous to the underlying concept of an open internet.”

Why it’s no excuse…

The language of dissent can get a little, uh, heated (see Barry Adam’s colorful “Google AMP Can Go To Hell”) but a free and open internet is a public good we should be all getting behind. Keeping Google from controlling the entire universe is a definite good for free speech and democracy. (And it’s better for business too.)

But so is delivering fast speeds so that more people can access the web. And AMP helps with that, big time. Remember, the loss of net neutrality means providers can potentially throttle speeds, offering “slow” and “fast” lanes depending on what customers can afford. And 70% of connections globally will remain 3G or slower through 2020 regardless. For these reasons, AMP seems downright necessary, and that’s why news organizations—like The Guardian and The New York Times—were among the first to adopt it.

For what it’s worth, Google has pled innocent in the court of public opinion. In September they took steps to distance themselves from the AMP Project by adopting a new governance model that includes other companies. What this means is that—though Googlers conceived and shepherded AMP—its future is now squarely in the hands of a group that may not always act in the tech giant’s interests. That’s a very good thing.

Why marketers should implement AMP

It’s well-known that delays can create anticipation. But make no mistake, your sluggish website in no way resembles the slow, sultry, seductive pour of Heinz ketchup onto a plate of golden french fries. In fact, the experience has more in common with waiting for your number to be called at the DMV.

By making prospects sit through delays, you’re serving up a heaping helping of frustration, annoyance, and uncertainty. All before they ever even see your content…

…or, rather, if they ever see your content. Because many of ’em won’t make it that far. In Unbounce’s 2019 Page Speed Report for Marketers, a majority of consumers told us that they’ll wait 4-6 seconds before giving up on a slow page.

A majority of consumers say they’ll wait 4-6 seconds before clicking away (via Unbounce’s 2019 Page Speed Report).

Data gathered by Google says the actual number is closer to 3 seconds. After that, many consumers told us they close their browser or even go to a competitor’s site instead. 45% of them told us that a slow loading site makes them less likely to make a purchase. If you want to get fast—like, really, really fast—AMP can get you there.

Unbounce + AMP

It’s no secret we’re bullish on AMP at Unbounce. That’s because Accelerated Mobile Pages have many tangible benefits as a quick way to create a near-instant visitor experience. Not only can they have a dramatic effect on your conversion rates, but they can also increase organic traffic overall and improve Quality Scores in Google Ads.

We were surprised to learn in the Page Speed Report how many marketers are avoiding AMP due to difficulty with developer resources. So, as part of our initiatives to improve page speeds, we’ve sought to make AMP friendlier to the non-developer, reducing or eliminating frustration. You can now drag and drop together AMP experiences, and we’re walking you through what AMP is, why you need it, and how to implement it.

So what’s the ultimate reason you no longer have an excuse for not implementing AMP?

Because we’re making it much easier.

In the coming weeks, we’ll be making AMP landing pages available to all Unbounce customers. Using them can still mean choosing efficiency over flashy scripts, but we’ve already seen our beta test community finding new ways to balance beauty and speed. We’re excited to hear how AMP landing pages impact your conversion rates when they hit. And I’m excited to start sharing some success stories (and actionable takeaways) with readers of this blog.

from Marketing https://unbounce.com/online-marketing/why-marketers-should-implement-amp/ via http://www.rssmix.com/