What is Teak?

Teak is collection of high-quality HTML templates created by digital agency for digital agencies and freelancers.

It’s created under our Themeforest brand name, Themejack. We’ve invested our knowledge and experience working for agency clients to create this high-quality product.

Product is responsive, supported by Bootstrap and it also comes with 2 color themes. In addition, we’ve optimized every part of our code to have perfect results on page speed tests across the web and the page speed results reflect that.

Learn more and buy

For more information and demo content visit our product page on Themeforest.

The post Teak — High Quality HTML Templates for Your Portfolio appeared first on Slicejack.

About two weeks ago, between June 14th and June 16th, we’ve visited the capital of Serbia, Belgrade and the biggest WordPress conference in this part of the world.

The city of Belgrade

We’ve used our free time for roaming around the streets of Belgrade, sightseeing, and of course tasting the local food and drinks. Although it’s a fairly big city, with lots of traffic we were able to walk around freely. The tram network is well organised and most of the time we didn’t notice any larger traffic jams. The city itself has lots of historic monuments and buildings and while we, unfortunately, weren’t able to to see them all due to attending the conference and few rain showers, we still snapped plenty of photos.

Local food is definitely one of the strongest advantages of Belgrade. There is so much local restaurants so it’s really hard to choose the best among them, but we would recommend the Jazz Cafe if you want to eat somewhere inside the city, and Time Out is a great beach bar and restaurant right next to river Dunav located on newly built Belgrade Waterfront, which we definitely recommend as a must go because of the magnificent view and chill out atmosphere. If you want a good local drink, we found the Jelen beer to be really good.

Conference

We had really high expectations from this conference and to be honest, it exceeded them all. From talks, workshops, stands to food, drinks and networking, organisation was spot on. With 2 tracks and 33 speakers in two days, some would expect it to be too much, but that was most certainly not the case. The talks were interesting and informative, with just enough length to leave enough time for Q&A after each talk, and even 10 to 15 minutes of time left to check what’s coming next and move from one track to another if needed. We kicked off with Andromeda track and Adam Silverstein’s talk about Javascript APIs in WordPress, and went on to spend most of the first day on the Andromeda track. Other talks that we found the most interesting on the first day were When to use the API by Sean Blakeley, The Balancing Act of Caching in WordPress by Maura Teal, The State of WordPress Mobile by Cate Huston and Technical SEO to grow your WordPress business by Joost de Valk. One more talk we would like to mention from day one is Matt Mullenweg’s Summertime Update and Q&A. Of course, most talks revolved around the upcoming Gutenberg and we would like to point out key takeaways from Matt’s talk:

June:

• Freezing new features.
• Inviting hosts, agencies, and teachers to opt-in. (Including wp-admin users for http://WP.com )
• Mobile apps

July:

• 4.9.x. release with “strong invite” to install.
• Opt-out for wp-admin users on http://WP.com
• Bug triage
• Exploring “beyond the post” into site customization.

August and beyond:

• 100k+ sites having made 250k posts using Gutenberg
• Core merge, beginning the 5.0 release cycle.

And so the day one came to a conclusion, but the day two was nothing less exciting. We’d like to point out a few of the talks we found to be most interesting on the day two, even though all the talks were really great. In the morning we started with Intro to Drupal by David Needham, which we found to be one of our favorites in the entire conference, not because it gave us some technical knowledge, but because it gave us a different perspective and showed us that there are other communities out there aside from WordPress community and encouraged us to connect with each other and help each other grow, and the speaker coming from the world of Drupal himself, the message held even heavier meaning. All the Gutenberg talk made us want to try it out immediately, so we did :). We joined Gutenberg Block Development with React workshop and got to know how to build our own Gutenberg block. Later we found even more of Gutenberg in depth, with Tammie Lister’s talk about the Anatomy of a block: Gutenberg design patterns, and Beyond Gutenberg by Matías Ventura. Aside from talks we would also like to point out how approachable the people at the stands were. We got to talk with the most of stands and everyone seemed to share the same opinion, that this years WordCamp Europe really felt like it brought people together and getting to know someone was never easier. And we share the same opinion, this years WordCamp Europe really hit the spot.

Conclusion

We genuinely had a great time at this years WordCamp Europe, and Belgrade really set the bar up high, but nonetheless we are looking forward to next years WordCamp Europe which will be held in Berlin, Germany. If you see us there don’t hesitate to approach us, we will gladly buy you a beer and have a talk :).

The post Slicejack at WordCamp Europe 2018 appeared first on Slicejack.

Between 29th of April and 1st of May we’ve visited an awesome city of Leeds and All Day Hey conference.

What? Where? Why?

All Day Hey is a single-track, single-day front-end conference held in heart of the United Kingdom, Leeds.

It has been organised by well known front-end architect Harry Roberts (@csswizardry), that was a very good reason to buy a plane tickets to the United Kingdom. Furthermore, looking at list of speakers it was obvious that we have to attend this one.

London and Leeds

On a first day, we came to London by a plane and then took the train to Leeds. While waiting for the train we spent a few fun hours in London, take a look at our gallery :). In Leeds we had only one sunny afternoon to explore the city, try local food and local beers.

A post shared by slicejack (@slicejack) on Apr 30, 2018 at 7:40am PDT

A post shared by Alen Vuletić (@alen_vuletic) on May 2, 2018 at 12:34pm PDT

Conference

We’ve visited quiet few conferences in last five years and from a front-end point of view this one was a success and we recommend it! I want to highlight few things that make it stand out:

1. Speakers: They were selected very carefully along with topics. Furthermore, topics were scheduled in a meaningful order, every talk was a perfect extension of a previous one.
2. Quality over quantity: Organisers did everything to make us feel comfortable. Venue (unique boutique cinema) was very comfortable and we felt like home (thanks for popcorns!). Everything was on schedule and everyone had their own seat. This are the reasons we love small size conferences!
3. Networking: There was no Q/A sessions after the talks but we were able to talk to speakers during coffee and lunch breaks, they were open for discussion as always.
4. Affordable: In the end, tickets are fairly cheap and Leeds is very well connected with London and rest of the world.

Talks and speakers

Speakers did a great job and they come up to expectations. Usually you don’t like every talk on conferences you attend but not in this case, we’ve enjoyed every minute of it.

Here’s a quick overview of talks:

• Unlocking the Power of CSS Grid Layout
  • Rachel Andrew
  • CSS grid and CSS standards
• Building Resilient Frontend Systems
  • Ian Feather
  • Infrastructure, disaster recovery
• What is the Web without the Browser?
  • Peter Gasston
  • Extended reality, future of the web
• Idea to Execution, and Beyond
  • Ashley Baxter
  • Product development, entrepreneurship
• Lightning Talks
  • Chris Kershaw (Weight training)
  • Ben Eaton (Digital art)
  • Chris Witham (Mental health)
• CSS – Past, Present, and Future
  • Una Kravets
  • Modern CSS, Houdini
• In the Loop
  • Jake Archibald
  • Event loop, JavaScript programming

Conclusion

We had a great time, learned a lot, met new people, tried new food and seen new places. Thanks All Day Hey crew, we’re looking forward coming next year!

The post Slicejack at All Day Hey — Leeds 2018. appeared first on Slicejack.

When creating an experiment for the first time, Optimizely and Google Optimize come on the scene after you’ve generated a hypothesis about what can be changed on your web page that will result in a higher conversion rate. They are tools for developing those variation(s), run the experiment and collect data about users activity on both control and variation. But as you run experiments you can use its results in first phase of CRO, when collecting data (e.g. segmentation of results) because from good experiments (even if variation failed) you can learn a lot about a users behaviour and it can help you spot problems and generate new hypothesis and come up with new experiments.

Either you own a business or you are CRO expert or developer looking for the right tool for your client I will try to cover pros and cons of Google Optimize and Optimizely. In a way, this comparison might not seem fair since I am comparing a free tool such as Google Optimize and the premium Optimizely, but the article might help you get an idea of what both tools provide and which one is more suitable or suitable enough for your business and experiments.

I will make a comparison in terms of the following steps in the process of creating variations and running an experiment:

1. Setting up
2. Development of variation
3. Defining and tracking conversion goals (click, page-view, sign-ups etc)
4. Defining audience
5. Test and run experiment
6. Reporting

Setting up and integration

Implementation of Optimizely will require inserting an Optimizely code snippet in the head of your HTML file and you are ready to go.

For installing Google Optimize, you first should have a Google Analytics account and add the Optimize snippet inside GA tags. You will have to link your GO project to the one in Google Analytics and install the Chrome extension to start developing variations.

Variation development

The complexity of variables that needs to be developed can vary from colour change of the call-to-action button to complete redesign of the page and changed functionalities. For a simple change as a button colour change or changing some headline, you might not need a developer but basic knowledge of HTML and CSS is advisable because just clicking around and hoping for the best can lead to poorly set up experiments that your business surely won’t benefit from. For more complex changes, HTML and CSS won’t be enough, you will need to use Javascript.

Let’s get back to simple changes for now. Both Optimizely and Google Optimize provide a Visual Editor Page that you want to run an experiment on and is loaded into the editor. Simply by clicking elements like buttons, text, headlines, you can make desired changes. You can see in the screenshots below what type of changes you can easily make without writing a single line of code. As you can see, editor’s options are quite similar and there is no big difference between them when it comes to the type of changes you can make without writing a single line of code.

(screenshot)

When changes are a bit more complex, Visual Editor might be not enough, so there are CSS and Javascript Editors implemented in both products.

Here are requests you might stumble upon when developing new variations.

— you want to make changes only on an element itself (change colour, text etc)
— you want to make changes in variation (you want to reorder elements on the page, insert content before/after some element etc)
— you want to make changes on the experiment (run custom code that will fire on both control and variation)
— you want to run code on the entire project (on each experiment)

Optimizely deals with all of these situations. It has separate editors for each scenario and takes care of code execution timing – project JS will be executed first, then experiment JS and finally variation JS.

Google Optimize on the other hand deals only with the first one quite well. Code that is related to an element itself, like colour change, text change, adding custom styles etc. can be added in a simple way, but everything else requires some workarounds. To run code on the entire variation one solution would be to target the <head> element and write a script. To run the same code on more variations at once, you will have to do it repetitively, meaning add it to each variation’s head.

Optimizely also comes bundled with jQuery but if you want to use the version on your site or not use it at all you can simply uncheck the option in the Settings page.

Setting up conversion goals

To actually track visitor’s interaction with both control and your variation, you will have to set up tracking of conversion goals. Goals can be clicks on the call-to-action buttons, landing on a specific page or some custom goal like the completion of the first step of your form etc.

Optimizely offers easy set up for tracking conversion goals for:

— clicks
— page-views
— custom goals

The custom goal is goal triggered by the code, but page view and click is something that a user can set up within a minute without writing any code.

Conversion goals in Google Optimize are called objective. You can set up:

— objective based on the goal that is already defined in Google Analytics
— bounces (number of single-page visits
— page-views
— session duration
— custom objective ( defining an event like in Google Analytics)

Optimizely allows you to have as many goals as you want, Google Optimize has a the limitation of 3 goals per experiment.

Defining audience

After segmentation of your results often you will have a need to run experiments targeting only a specific group of people (just desktop visitors, users coming from UTM campaign, based on user’s location etc.), so for your A/B experiment, you will need to define the audience. (List all audiences from GO and Optimizely). You can see from the lists below that Audience options are quite similar in both tools. Optimize 360 (premium Google Optimize version) has a nice feature of being able to set audience based on GA data. Meaning you can target a more specific group of the people. For example, you can target only visitors that in the past have purchased some item which can be convenient if you have that kind of request for your experiment since in Optimizely a solution won’t be so straightforward.

(screenshot)

QA experiment

Before setting the experiment live, it is important to test it out so you can be sure that everything works as expected. If you are setting up a web page across different devices, make sure it looks and works well on all screen sizes. Also, it is important to test if goals/objectives are firing correctly.

QA using Preview mode

Both tools provide Preview mode and give you an option to share a preview with other people involved in the experiment. Preview mode helps you test out variations across browsers and devices, Optimizely’s preview mode also logs goals fired during testing. Preview mode won’t be enough if you want to share the experiment with users that don’t have access to Optimizely or Google Optimize projects.

QA using a test cookie

You can test out your experiment by setting up a test cookie and targeting only an audience that has a cookie that you defined as the test cookie. In that case, you started your experiment so you are able to check if goals are fired if results are logged the way you expected and of course if it visually looks like it should.

Optimizely even gives you an option to force a variation, so you just add a query parameter optimizely_x=VARIATIONID inside your URL and you will be bucketed in the desired variation. In this case, you don’t have to keep reopening an incognito window and wait to be bucketed in variation(s) to test it out. Google Optimize, unfortunately, doesn’t have this option.

In Optimizely, after you tested out the experiment, you can pause the test, reset the results, remove the test cookie audience and set the experiment live – show it to “real” users.

After you pause the experiment in Google Optimize there is no option to reset results and start it again. Once started you won’t be able to edit the experiment so if you spot some bugs during QA you can’t pause the test and fix it on the current experiment, you will need to copy the experiment, fix the issues and start it again. If you are testing the firing of goals (objectives) the whole process will last more than it should, considering the fact that the results are generated with a few hours delay. So, you won’t be able to tell immediately if your experiment works well. Ater a few hours, when your testing activity is logged, you might see that it is not working as expected. So you copy the experiment and you make changes and fix things that you assume or know are causing the problem, run it again with the test cookie audience test and wait for a few hours until new results are generated. If everything is working well now, you will need to copy the experiment again and set it live.

Reporting

Optimizely and Google Optimize have a different approach when it comes to counting conversions. Google’s reports are session based, meaning it might count the same visitor twice if they started two different sessions. Optimizely, on the other hand, is unique visitor based, so it won’t count the same visitor and conversion twice. They differ also in the statistical method they use when determining the winning variation. Google Optimize uses Bayesian methods and Optimizely uses Frequentist approach. In my previous article, I briefly described those two methods and linked some useful articles if you want to dig deeper into the subject.

Reporting in Optimizely is almost live, meaning you can see visitor’s conversions immediately or with a few minutes delay. Google Optimize on other hand has a big delay. It has up to 12 hours delay and this can be very frustrating if you are testing out experiments before setting them live. You are not able to see results on the same workday if something needs to be fixed.

—

As I mentioned in the introduction, I didn’t want this article to be about what is better or what you should go with. Different projects have different requests. GO being completely linked to GA is both an advantage and disadvantage. If you are already using GA or you are planning to use it and your experiments won’t reach really complex phases, then GO should be a very good solution considering it’s a free tool and has a fair amount of features and options. Optimizely is a more professional tool and will serve you well through all phases of creating an experiment.

There is another very popular tool in the A/B testing scene – VWO and we have been testing it out too so in the future you can expect another comparison from us.

The post A/B Testing: Optimizely vs. Google Optimize appeared first on Slicejack.

In web analytics, it means comparing two versions of the same webpage to see which one performs better. Differences between two variations can be minor like a button colour change or a complete redesign of a page. In practice, half of the visitors will be shown version A and the other half will see the B version. By tracking visitor’s engagement on both control (A) and variation (B) over some period we are able make the conclusion of which variant results in a better conversion rate.

What is a conversion, conversion rate and CRO?

A conversion is the desired action that a user completes when visiting a web site. A conversion might mean purchasing a product, signing up for a newsletter, signing up for a trial period, etc. So, a conversion would be any visitor’s activity that is important for a website’s success. Its specific to websites. Something that is considered a conversion on one website, might not be an important action on another one.

Websites and apps often have multiple conversion goals, and each will have its own conversion rate. A conversion rate is the number of conversions divided by the total number of visitors. Improving conversion rates is known as conversion rate optimisation (CRO).

A/B testing is the most common process used for conversion rate optimisation.

There is no universal A/B test because each web site requires an individual approach. Although there are some elements that are usually tested:

• Call-To-Actions – placement, wording, size.
• Copywriting – value propositions, product descriptions.
• Forms – their length, field types, text on the forms.
• Layout – homepage, content pages, landing pages.
• Product pricing – try testing for revenue by testing your prices.
• Images – their placement, content and size.
• Amount of content on the page (short vs. long).

Conversion optimisation requires a methodical approach and implementation of good A/B testing is achieved by the following steps:

Research phase

In the research page your goal is to collect as much information as you can about the user experiences of your webpage and how visitors interact with it, to understand why they act the way they do. It will help you make assumptions about what is causing for instance, low conversion rate of clicks, sign-ups, why your landing pages have high bounce rates, etc. To get a fuller picture in this phase, it is advisable to use web analytics tools, heatmaps, session recordings and to get user’s feedback in the form of surveys, chat etc.

You can find what is happening on your site by using Google Analytics; what features they use, what they don’t use, but Analytics won’t give you an answer about why visitors did or did not convert. The best way to get qualitative data from your visitors is through surveys.

When possible, always segment your analytics data because it will give you deeper insight. For example, your overall data might be telling you you’re your landing page is not performing well but when looking into the segments, you might see it is performing well on mobile phones.

It’s important to spend more time in the research phase because diving deeper into problems will help you come up with right hypothesis and help you develop higher quality testing.

Sometimes the research phase will reveal many problems across different pages on your website. Before continuing with A/B test preparation, you should prioritize your problems.

Pages that are the most important for your business should be tested first. Those can be pages with sign-up forms, checkout pages, etc. Also, pages with high traffic should have the advantage when testing, because tests on high-traffic pages finish sooner so you can move on to the next tests faster, which will in the end speed up your optimization process.

Generate hypothesis

After using all the tools you had in the research phase, getting insights into visitor behaviour and after you’ve spotted problems on your webpage, it’s now time to come up with a hypothesis as to why there are problems with your conversion rates or bounce rates. Your hypothesis should state clearly what is being changed, what you believe the outcome will be, and why you think that’s the case.

For example: you saw your users are giving up after filling out three to four fields on your sign-up form. Your hypothesis in this case could be

‘A Shorter form might encourage visitors to fill it out completely’.

When creating the hypothesis it’s important to be as specific as possible. Testing one change will help you understand what changes had an effect on your visitor’s behavior, and which ones did not. Over time, you will be able to combine the effect of multiple winning changes from experiments and create more powerful tests.

A bad hypothesis in this case would be:

‘Redesign of sign-up page will encourage visitors to fill it out completely’.

Why this is bad?

• This is not what your analytics are saying to you. Your visitors did start to fill out sign-up form so you probably are doing something right on the webpage.
• Redesigning whole page won’t help you learn from this problem. Your variation might have a better conversion rate, but are you sure you will know why that is? Your variation might be a loser and you still won’t know why that happened, so you will be at the beginning again.

So more specific hypotheses and smaller changes on variation(s) are what you will benefit from. When a test is based on pedantic research and a clear hypothesis to test, you will learn about your audience after each test.

Of course, sometimes you won’t be able to apply just small changes, because sometimes big problems that need to be resolved will require big changes.

Create variation(s)

Now you have an assumption about why visitors are not converting as much as you want and it’s time to design and develop variation(s) based on your hypothesis. You can have as much variations as you want when setting up an experiment. So, if you want to have control (original) and create 2 variations, that is completely OK but keep on mind that if your site is not getting much traffic, you might end up waiting for significant results for ages.

For creating a variation you will usually need a designer and developer, depending on the changes you want to make and which tool you are using for implementing the variations. The changes can be changing the colour of a call-to-action button, reordering elements on the page or something more complex. Most leading A/B testing tools provide a visual editor, so some small changes can be made very easily and promptly.

You can see on the image below that you can make changes simply by clicking elements inside the visual editor.  Some of the most popular tools are: Optimizely, VWO, Google Optimize. I will compare them in my next post.

Before starting an experiment, be sure you test it properly to make sure it works the way you want because if you notice some bugs afterwards it might make the whole test invalid. Also, if you are not skilled enough to make changes on your own, get help from a developer because you won’t have any benefit in a badly set up experiment.

Run the experiment

Once you’ve tested your variation(s) properly, across all browsers and devices and you made sure there are no odd things happening, it’s time to puts your experiment live. The A/B testing tools will take care of reporting and you will be able to see the number of visitors and conversion rates for your goals.

How long should you run a test?

There are a few online calculators that can tell you approximately for how long you should run a test or how big your sample size needs to be. VWO has a good calculator that will you give an idea of parameters that are important when calculating the duration of your tests. https://vwo.com/ab-split-test-duration/.

• The more traffic you have going through the pages tested, the quicker your test will complete.
• The more variations you run as part of a test, the longer you’ll have to wait for the test to complete.
• The lower your current conversion rate is, the longer you’ll have to wait. If your conversion rate is 5%, then your tests will complete quicker than if your conversion rate is only 1%.
• The lower your best variation’s performance, the longer you’ll have to wait.

For some high-traffic sites you will get the required sample size in a day or two. But that isn’t a good sample – it doesn’t include a full business cycle, all week days, weekends etc. So, to get a representative sample and for your data to be accurate, experts recommend that you run your test for a minimum of one to two weeks. By doing so, you will have covered all the different days.

We know for example that shopping behaviour during the weekend is different from shopping behaviour during weekdays.

If you want to analyze your test results across segments, you need even more conversions. It’s a good idea to run tests targeting a specific segment, so to have separate tests for desktop, tablets and mobile.

Along with the duration of your test, it’s important to determine if results are statistically significant.

What is statistical significance?

Statistical significance is a way of mathematically proving that a certain statistic is reliable. A result of an experiment is said to have statistical significance, or be statistically significant, if it’s likely not caused by chance for a given statistical significance level.

For example, if you run an A/B testing experiment with a significance level of 95%, this means that if you determine a winner, you can be 95% confident that the results are real and not caused by randomness. It also means that there is a 5% chance that you could be wrong.

Sometimes during the test, you might reach statistical significance a few times, so you must set a proper sample size to know when to stop the test. On the other hand, if you are running an experiment for a while and you still haven’t reached statistical significance, this means your test is inconclusive.

Analyse Results

There are three possible scenarios after your experiment is finished:

• Your variation is a winner

Good job. You set up your hypothesis very well and next step is to implement those changes and show your new design to 100% of your visitors. But keep in mind that you can always look for improvement and having a winning variation on some page doesn’t mean you should stop analyzing and making new hypotheses and running new tests.

• Your variation is a loser

This is a very common situation and you shouldn’t be disappointed. Look at the data and segments and try to understand why the test failed. You will learn something from the results and you will apply that knowledge when making new hypotheses and setting up new tests.

• Test results are inconclusive

This means that your experiment has been running for a considerable amount of time and you didn’t reach any significance. This usually happens when your hypotheses are wrong, or your test didn’t differ much from control, particularly on lower traffic sites. Although, often you will find that one of the variations was a winner in a specific segment. That’s an insight you can build on. If you have a test which failed on all segments, revise your hypothesis and test again with new ones.

Statistical methods behind determining the winner of A/B testing

Two commonly referenced methods of computing statistical significance are Frequentist and Bayesian statistics.

The Frequentist approach is most often used by A/B testing software. It means making predictions using only data from the current experiment. Optimizely uses Frequentist methods to calculate statistical significance because they offer ‘guarantees’ about future performance: statistical outputs from an experiment that predict whether or not a variation will actually be better than the baseline when implemented, given enough time.

Bayesian tests make use of past knowledge to calculate experiment results. That past knowledge is encoded into a statistical device known as prior, and this prior is combined with current experiment data to make a conclusion. Using previous information should lead to the quickest experiment progress. Provided that the assumptions made using historical data to calculate the statistical prior are correct. This should help experimenters to reach statistically significant conclusions faster. But there is a risk that prior experiment knowledge may not actually match how an effect is being generated in a new experiment, and it’s possible to be lead to an incorrect conclusion. VWO and Google Optimize use the Bayesian method.

If you are interested more in this topic, I recommend you to read these articles:

https://conversionxl.com/blog/bayesian-frequentist-ab-testing/

https://blog.optimizely.com/2015/03/04/bayesian-vs-frequentist-statistics/

Conclusion

A/B testing, apart from being a method for increasing your conversion rates, will help you learn about your visitors and give you valuable insights about their behaviour which in will lead to more powerful tests and a bigger increase in conversions. Not all of your A/B tests will be successful, but that shouldn’t be something that will stop you from testing. You will start seeing considerable website performance improvements after a few different experiments. And remember, no matter how well your landing page or sign-up page is doing, there is always space for improvement.

The post Introduction to A/B Testing appeared first on Slicejack.

This installment will only cover implicit grids, item layering, and aligning grid items and tracks.

Implicit grid

The explicit grid is defined by using the relevant CSS grid properties, like grid-template-rows, grid-template-columns and grid-template-areas.
But what if only 3 columns and 2 rows are specified, and item is placed outside this grid?
In that case, the browser will create an implicit grid to hold that item.

In a simple 3×2 grid (colored part), the grid column lines only go up to 4. But if we place an item in the 5th column, the browser will add 2 implicit columns to accommodate this item.

The size of these implicit grid tracks can be specified with the grid-auto-columns and grid-auto-rows properties. If these properties are not set, their default value is auto, which results in the implicit columns filling up the available space equally.

Grid items that are not explicitly placed will fill the grid up accordingly.

Layering grid items

Multiple items can be placed in the same grid cell, and can be layered by using z-index.

item-1 is positioned between columns 1 & 3, and rows 1 & 2. item-2 is positioned between columns 1 & 4, and rows 1 & 3.

By default, item-2 would sit on top of item-1; however assigning z-index: 1 to item-1, will result in it sitting on top of item-2.

Aligning grid items

Grid items can be aligned by applying justify-items (along the row axis – left to right) and align-items (along the column axis – top to bottom) properties on the grid container.
These properties support the following values:

• start – aligns the content to the left/top end of the grid area
• end – aligns the content to the right/bottom end of the grid area
• center – aligns the content in the center of the grid area
• stretch – fills the whole width/height of the grid area (this is the default)

Individual grid items can be self-aligned with the justify-self (along the row axis – left to right) and align-self (along the column axis – top to bottom) properties.
These properties support the following values:

• start – aligns the content to the left/top end of the grid area
• end – aligns the content to the right/bottom end of the grid area
• center – aligns the content in the center of the grid area
• stretch – fills the whole width/height of the grid area (this is the default)

Aligning grid tracks

Sometimes grid size can be less than the size of its grid container. In this case, grid tracks can be aligned relative to the grid container with justify-content (along the row axis – left to right) and align-content (along the column axis – top to bottom). These properties support the following values:

• start – aligns the grid to the left/top end of the grid container
• end – aligns the grid to the right/bottom end of the grid container
• center – aligns the grid in the center of the grid container
• stretch – resizes the grid items to allow the grid to fill the full width/height of the grid container
• space-around – places an even amount of space between each grid item, with half-sized spaces on the far ends
• space-between – places an even amount of space between each grid item, with no space at the far ends
• space-evenly – places an even amount of space between each grid item, including the far ends

Final thoughts

With this article, our “Introduction to CSS Grid Layout Basics” series is done.
It’s in no way a definitive all-in-one guide, but hopefully it will put you on a right track to learn more about CSS grid. Hope you found it helpful.

Resources

• Complete Guide to Grid on CSS Tricks
• Complete Guide to CSS Grid on Codrops
• learncssgrid by Jonathan Suh

The post Introduction to CSS Grid Layout Basics – part II appeared first on Slicejack.

The conference is held anually, this was the fourth installment of the event and was visited by more than 1200 professionals working in the area of experimentation.

The event lasted for three days. Aside from the education lectures, keynotes, developer night and certification workshops the main part of the conference were 24 breakout sessions divided into three tracks:

1. Bold ideas for growth (intended for practitioners)
2. Creating a culture of experimentation (intended for decision makers)
3. Data, developers and product management (intended for developers, analysts, and product managers)

The breakout sessions were held by representatives from companies like IBM, Microsoft, New York Times, Optimizely, etc., where they talked about their approach to experimentation and how they use the Optimizely platform.

The sessions ranged from concrete topics like how Optimizely integrates with React to high level topics such as how to organise an experimentation program within your organisation.

Optimizely introduced a whole lot of new upgrades that they will be rolling out to the Optimizely X platform:

1. Program Management
2. Feature Management
3. Support for Dynamic Websites
4. Stats Accelerator

You can checkout the whole list in detail here:

All the announcements from #Opticon2017 https://t.co/bbjcdYqZ2o #technews #cronews #icymi

— Optimizely (@Optimizely) October 30, 2017

But I would say the key takeaway and trend that clearly resonated throughout the conference was about “Building a Culture of Experimentation”. This is something Dan Siroker explained in his keynote opening of the conference.

The culture of experimentation is a fundamental shift in how you approach the development of your product or service.

In the old development approach you would assume how to improve your customers experience and then you would build a new version of your software/app/whatever based on that assumption.

In the culture of experimentation approach, you would assume how to improve your customers experience and then you would test that assumption in an experiment without full-scaling the assumption. If the experiment fails you would simply shut it down and continue with the original. Every idea in your business is considered an experiment that needs to be validated before full-scaled.

Optimizely basically streamlines this process, using this approach is a growing trend and it’s benefits are perfectly illustrated by the graph below.

The forture 1000 have collectively grown their market cap by 56% over the last 5 years. But the companies that truly embodied a culture of experimentation have grown their market cap by 765% in the same time.

It’s the approach they use at Amazon as said by their CEO.

—

See more photos below.

The post Opticon 2017 – Las Vegas appeared first on Slicejack.

Enter the CSS Grid Layout.

What is it?

CSS Grid Layout or simply ‘Grid’ is W3C’s solution for the layout problem we’ve all been tackling since the birth of the web. It’s the latest CSS module that provides us with a two-dimensional grid-based layout system. Basically, it enables us to align elements into columns and rows. But not just that! With it’s more advanced features, creating complex page layouts is a breeze.

Is it well supported?

According to caniuse.com, CSS Grid’s global browser support is around the 71% mark. Thats’s pretty good, but not good enough to use in most production environments just yet. However, you can always check the browser statistics for the website you’re working on and decide whether or not the Grid layout is worth implementing.

Here is a ‘per browser’ support screenshot:

For more details click on the image or the link above.

Any new terms I should be aware of?

There are a few new terms and concepts associated with the Grid spec that you need to get comfortable with so you can learn to use the grid properly and unlock it’s full potential.

Grid container & grid items

Grid container is the container element on which display: grid is applied. The children that are direct descendants of the grid container are grid items.

Grid lines

Grid lines are the horizontal (row) and vertical (column) lines that form the grid structure. They are used to position grid items inside the grid. Each one has a numerical index associated with it, starting with 1 from the start of the grid, or -1 starting from the end of the grid.
In the example below, there are 4 column grid lines and 4 row grid lines that form the grid. Column line 3 (from the start)/-2 (from the end) is highlighted.

Grid cells, tracks, areas

A grid cell is the space between 2 adjacent row grid lines and 2 adjacent column grid lines. It’s a “basic grid unit”, conceptually similar to a table cell. In the example below, the grid cell is the highlighted part between the 2^nd and 3^rd row grid lines, and 3^rd and 4^th column grid lines.

A grid track is the space between 2 adjacent grid lines. Essentially, you can think of the grid tracks as the rows and columns of your grid. In the example below, the grid track is the highlighted part between the 1^st and 2^nd row grid lines.

A grid area is the space surrounded by four grid lines, made up of multiple grid cells. In the example below, the grid area is the highlighted part that takes up 4 grid cells, and is surrounded by the 2^nd and 4^th row grid lines, and 1^st and 3^rd column grid lines.

How does it work?

Grid container

Grid container can be created by setting the display property with a value of grid or inline-grid. All direct children of the newly created grid container become grid items.
When display: grid is used, grid items are placed in rows by default and span the full width of the grid container. On the other hand, display: inline-grid will make the grid as wide as the widest grid item (similar behaviour as display: inline-block).

Rows and Columns

grid-template-rows: 70px 100px

A row track is created for each value specified for grid-template-rows. Track size value can be a length, a percentage, a fraction of the free space in the grid (using the fr unit), or a keyword auto, which will fill up the remaining space available.

In the example below, items 1 and 2 have fixed heights of 75px and 100px. Because only 2 row tracks were defined, heights of items 3 and 4 are defined by their contents.

grid-template-columns: 150px 75px 200px

A column track is created for each value specified for grid-template-columns. Like rows, track size value can be a length, a percentage, a fraction of the free space in the grid, or a keyword auto.

In the example below, grid items 1, 2 and 3 have fixed widths of 150px, 75px and 200px. If you add 3 more grid items (items 4,5,6), they will be placed on a new row track because only 3 column track sizes are defined; and their column sizes will be equal to items 1, 2 and 3.

grid-template-rows: minmax(100px, auto);
grid-template-columns: minmax(100px, auto)

For both grid-template-rows and grid-template-columns, the minmax() function can be used to define the minimum and maximum track size. It accepts 2 arguments: the first is the minimum size of the track and the second is the maximum size. Besides length values, the function also accepts the keyword auto, which allows the track to grow/stretch based on the size of the content.

grid-template-rows: repeat(3, 150px);
grid-template-columns: repeat(4, 1fr)

repeat() function can be used to create a grid with multiple items that have the same size. It accepts 2 arguments: the first one represents the number of times the defined track should repeat, and the second is the track definition.

repeat() can also be used within track listings. For example grid-template-columns: 50px repeat(3, 100px) 50px. This will create 5 column tracks. First and last column tracks will be 50px wide. The 3 tracks in between will be 100px wide each.

Grid gaps (gutters)

Grid gaps between rows and columns are created by using grid-column-gap and grid-row-gap properties, or the shorthand grid-gap property that combines both.

grid-row-gap: 30px;
grid-column-gap: 15px

is the same as

grid-gap: 20px 15px;

Assigning names to grid lines

By default, grid lines have a numerical indexes associated with them. They can also be assigned a name when defining the grid with the grid-template-rows and grid-template-columns properties. Those names can be used instead of the numerical indexes to position grid items inside the grid.

grid-template-rows: [row1] 1fr [row2] 1fr [row3];
grid-template-columns: [col1] 1fr [col2] 1fr [col3]

Grid lines can have multiple names assigned to them: grid-template-rows: [row1-start row-first] 1fr [row1-end row2-start] 1fr [row2-end row-last].

Lines can also be assigned the same name with the repeat() function. Lines with the same name are also assigned a occurrence number for easier identification.

grid-template-rows: repeat(2, [row-start] 1fr [row-end])
grid-template-cols: repeat(2, [col-start] 1fr [col-end])

Assigning names to grid areas

Just like grid lines, grid areas can also be named with grid-template-areas property. These names can be used to position grid items inside a grid.

grid-template-rows: 1fr 1fr 1fr;
grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "header header header"
"content content sidebar"
"footer footer footer"

Positioning grid items

Grid items are positioned by grid lines or grid areas.

Item positioning by grid lines

Grid lines can be referenced by their numerical index or name.

grid-row-start: 2;
grid-row-end: 3;
grid-column-start: 2;
grid-column-end: 3

is the same as

grid-row: 2 / 3;
grid-column: 2 / 3

is the same as

grid-area: 2 / 2 / 3 / 3

Here is the same example using grid line names:

grid-row-start: row2;
grid-row-end: row3;
grid-column-start: col2;
grid-column-end: col3

is the same as

grid-row: row2 / row3;
grid-column: col2 / col3

grid-area shorthand can’t be used with grid line names.

If the grid line names are generated using the repeat() function, generated occurrence number also needs to be specified, separated by whitespace.

grid-row: row-start 2 / row-end 2;
grid-column: col-start 2 / col-end 2

Grid items by default, span only one row and column track, but can span multiple row and/or column tracks using the same properties to position them.

grid-column-start: 1;
grid-column-end: 4

is the same as

grid-column: 1 / 4

is the same as

grid-column: span 3

Same logic can be applied to rows:

grid-row-start: 1;
grid-row-end: 3

is the same as

grid-row: 1 / 3

is the same as

grid-row: span 2

The keyword span, is always followed by the # of columns or rows to span.

Item positioning by grid areas

Let’s reuse the example found in the ‘grid area naming’ section and position a grid item inside the header area.

grid-row-start: header;
grid-row-end: header;
grid-column-start: header;
grid-column-end: header

is the same as

grid-row: header;
grid-row: header

is the same as

grid-area: header

Final thoughts

That’s it for the ‘part I‘ of the ‘Introduction to CSS Grid Layout Basics’ series.
‘part II‘ will cover implicit grids, item layering, and aligning grid items and tracks.

Resources

• Complete Guide to Grid on CSS Tricks
• Complete Guide to CSS Grid on Codrops
• learncssgrid by Jonathan Suh

The post Introduction to CSS Grid Layout Basics – part I appeared first on Slicejack.

City of Berlin

We are very thrilled when we talk about Berlin. City is vibrant, public transport is very well organized and it has everything one metropolis should have.

The incredible variety of cafes and restaurants is what makes Berlin stand out in the masses of cities of similar size. And the most important thing, people are open and very kind.

Conference

CSSconf EU is a not-for-profit community conference run by a team of volunteers. This was the largest CSSconf EU ever with top international speakers, interesting talks and great community area. The conference was held in Berlin’s Arena Halle and venue was huuuge!

Organisers did an amazing job! Talks were on time, atmosphere was great and there was plenty of quality food for everyone.

Talks

This year we had an opportunity to learn a lot from top-notch engineers, web designers and world-class speakers. All the talks were interesting and worth listening but I’ll mention just few of them.

Ivana McConnell

Firstly, @ivanamcconnell talked about “CSS and the hierarchy problem: What makes a CSS developer?”.  The definition of our profession is still unclear, and the stigma of “CSS is not REAL development” remains. Ivana dissected how power dynamics and implicit hierarchies threaten to devalue the work we do, and how that hurts us both individually and as a community.

Patrick Hamann

@patrickhamann showed us how we can improve CSS performance on existing and new projects. He talked about first meaningful paint, measuring performance, preload settings and server push. I’ve learned a lot from this talk and you should watch the replay when it comes out on YouTube.

Slides from my @CSSconfeu talk yesterday, “CSS and the first meaningful paint” are now up: https://t.co/HcbJ4f2kYk #CSSconfEU #jsconfeu

— Patrick Hamann (@patrickhamann) May 6, 2017

Rachel Andrew

@rachelandrew is an invited expert to the CSS working group. Her talk illustrated the standards process by which new CSS features come to fruition, traced how CSS came to be where it is today, and in the end, gave us an insight into how we can help shape CSS in the future.

Guil Hernandez

Guil Hernandez does a wonderful job of teaching CSS over at Treehouse, and it was amazing experience to see him live on stage. He talked about the future of CSS and gave us a lot of examples of CSS variables, compositing and blending, CSS shapes and clip paths. We will use this features very soon, you definitely want to learn some of them!

Thanks so much for having me today, @CSSconfeu — that was fun! Here are the slides from earlier. https://t.co/woTz5a1MGG

— Guil Hernandez (@guilh) May 5, 2017

Una Kravets

And the last speaker was Una Kravets. She build pure CSS game, live on stage! Una used SASS data structures, SASS functions, pointer events and pixel art to build simple but interactive game. It was interesting to see how she structured and built everything from scratch step by step. You can try the game on CodePen.

Pixel art isn’t that heart to do when you use @SassCSS! ❤ @Una doing some crazy live coding at @CSSconfeu: pic.twitter.com/t5m4LQaKgY

— David K. (@DavidKPiano) May 5, 2017

Thanks Berlin for amazing time and great conference! I hope we’ll meet again 

The post Slicejack at Berlin CSSconf EU 2017 appeared first on Slicejack.

Workshops were organised in partnership with StartupHR and Faculty of Electrical Engineering, Mechanical Engineering and Naval Architecture (FESB) in Split and we would like to thank them for the help they’ve provided.

Our goal and vision were to introduce web development to the youngest ones, students. It’s important to say that content was created for people without any experience in this field, HTML or CSS. Workshops were held in well equipped laboratory with 20 computers and about 30 people participated.

What did we talk about?

We did HTML and CSS for beginners. Focus was on foundations, we didn’t talk much about advanced things like HTML5, CSS animations and transitions.

On our first meeting we did HTML and we mentioned things like HTML tags, elements, structure, content etc.

Finally on second meeting we met CSS. CSS was used to have fun with colors, widths, font families and a lot of other things that CSS provides to us.

Gallery

Here you can see a few photos from workshops.

The post HTML / CSS workshops by Slicejack appeared first on Slicejack.