Chrome has been my default browser for many years now, but I’ve been thinking that my familiarity with just one browser has become a problem. If I tend to design for a single browser, then I’ll start to make assumptions that those features are available for everyone. Then I’m likely to miss important differences between browsers which could introduce bugs into the codebase or influence the amount of time I spend designing a feature.
I’ve started to call this problem “Chrome Bias”, and over the past week, I decided I would do something about it by switching to Firefox. This way I could figure out what’s new in one of the most popular web browsers out there. But! While I was running this little experiment of mine, I found three Firefox features that you might not know about if you suffer from extreme Chrome Bias like I do.
I think these Firefox developer tool features are pretty nifty:
Theming the Developer Tools
I didn’t know that you can set the theme of the Developer Tools in Firefox. That is particularly helpful for me when I want to work on something at night and can configure the theme to dark:
Fonts tab
Firefox’s font tab might not be new but it certainly is to me. On the far right you can select the tab and see the type info for whichever element you’ve selected:
It’s pretty neat that it tells you not only how to use that @font-face rule, but also the location from which the font is being requested as well. My favorite button here though must be the “See all the fonts used in the page” button which sits in the bottom-right hand corner. Once you’ve clicked that you can see every font-family that’s been declared in the stylesheet that’s served to the page:
I can see that being super helpful in larger codebases where you might accidentally have lots of fonts being declared inconsistently.
Performance tab
After you’ve hit the ‘Performance’ tab and refreshed the page, you’ll see a waterfall of every resource that’s been requested. But did you know that you can see this data in the form of a graph, too? Here’s how that works:
This is a great tool to identify bigger problems in performance—perhaps you have a massive stylesheet being requested by the browser, and from here you’ll be able to see the scale of the problem faster.
Wrapping up
Here’s the thing: the more we experience how other browsers work, the more we learn about how different users experience our websites. Understanding how developer tools differ was useful in this instance, but learning about how unfamiliar browsers look and feel is enlightening as well.
For the next step in my experiment, I want to try out more mobile browsers because I imagine the differences between them are even larger than those between desktop browser apps.
What tricks have you learned from your non-regular browser lately?
Technical skills at the highest level. You will see no difference to a high-resolution photo, but these are actually hand drawn paintings. Start doubting your eyes!
Last post I touched on the history of Ruby and the creator. As well as simple commands that would get you started writing simple Ruby programs. I am hoping that this post comes across as understandable as possible, because I will be getting into debugging your program, and what many of the keywords mean guiding you through what your test is telling you and how to fix it.
Using the IRB platform or Interactive Ruby, we are able to write Ruby commands directly into terminal, and execute your program. This is a Ruby Shell or REPL which stands for Read Evaluate Print Loop; think of it as a Ruby playground. Its purpose is for testing, playing, and manipulating your code for further understands. To begin simply type IRB (irb) into your terminal.
This is where you can test your code without changing the file you are actually working on, or test your program to see the result. Below you will see simple mathematical equations using puts (out*put s*tring) to output the string you want to display.
When you are writing code you will see a ton of error messages. This is expected! Something that I personally had to get over was not hiding from these, but viewing them as a clue to find where my logic is semantically incompatible. Errors in a program are a great tool to embracing and understanding, and understanding what they are telling you will help you build better tools. Error messages, for the most part, display three simple messages; where, why, who.
Where: Location of error
Why: The description
Who: The type of error
The “where” is the location of the error. Within the learn.co IRB text editor supplied by Flatiron, my simple error looks like the world may end…. But that is because a RSPEC test file is attached, which we will get into later but basically all you need to look at what I placed below.
Because the a RSPEC test suite file is attached you have to read the error a little differently. These are test applied specifically to your program within each assignment within the school, making your life easier when debugging your program. Generally tests found though Flatiron School call on the method you define in your programs and check to see if they are working the way you expect them to. But the test above states what error has failed “SyntaxError” and what is supposed to return true “unterminated string meets end of file” stating that the string was not terminated within your program properly. Terminating the string within this specific lesson will return true and pass the RSPEC test suite and allow you to continue learning through Flatiron School.
Flatiron School setting up their lessons this way is greatly beneficial to the student and one of my favorite parts about the school. It allows me as the student to navigate through the lessons test suite incrementally, until I have reached a resolution to pass the the course material. Keep in mind that the test suite usually returns four common error types.
Name Errors: Are caused when a given name is invalid or undefined.
Syntax Errors: They are the result of incorrect syntax.
Type Errors: When you try to do a mathematical operation on two objects of a different type. Ex: 2 + “2” = ERROR
Division Errors: Are caused when a given number is divided by zero.
I know when I first looked at all these errors, all I saw was gibberish. But once I understood what the return values meant that were being returned, everything made a lot more sense. We are almost ready to begin writing code! Haha
Keep in mind, just like most other programming languages there are roughly six different data types know as classes in Ruby which are booleans, symbols, numbers, strings, arrays, and hashes.
Booleans: The two values of the boolean data type are true and false. But, in Ruby there is actually no such thing as a boolean class, instead every appearance or instance of true and false in your program are instances of the true class and false class.
Numbers: For those of you who failed math, like me, integers are numbers. There are two types of numbers:
Fixnums: Whole numbers, like 8
Floats: Decimal Numbers, like 8.4
Symbols: A symbol is a representation of a piece of data
Arrays: Arrays are a collection of Ruby objects. Arrays can also store any type of data.
Hashes: Hashes store objects in Ruby, and operate kind of like a dictionary composed of key value pairs
I know this was a lot of definitions, but understanding the basic concept of what a language is comprised of and how to read output values is a key to furthering learning. Most of the concepts above can be transferred to many other programming languages and are pretty universal. Even though we did not get to cover very much code in this section of Flatiron School, I did get to walk away with the tools to understand future issues that may arise.
Nothing can ruin a design like typography that doesn’t fit. Whether it’s too big (or too small), improper type scaling is a major problem.
It’s a problem for more designs than you might think. Too commonly you visit a website where the type renders beautifully on a desktop browser, only to revisit later from a phone and find it difficult to read. It happens all the time.
The issue is that the type wasn’t truly scaled for each device. It’s a totally avoidable problem when you consider a typographic scale for projects.
What is a Typographic Scale?
A visual typographic scale encapsulates the sizes, space and proportions of type elements relative to on another in a project. This includes everything from the main body text style to headlines, subheaders, captions and any other text element.
The scale helps determine size and placement of the text elements in relationship to one another. For web design, in particular, the visual type scale often corresponds to tags in your CSS (such as h1, h2, h3, p, and so on).
A type scale helps you create harmony and rhythm in the design. It also keeps you out of stylistic trouble because text elements correspond with CSS elements so that every part of the design uses the same elements and consistency.
The scale should be based on the size of body text. (Always set a typeface and size for that first). Then build the scale around this main typography. Not sure where to start? Google has a solid recommendation:
Use a base font size of 16 CSS pixels. Adjust size based on properties of the font being used.
Use sizes relative to the base size to define the typographic scale.
Text needs vertical space between characters; the general recommendation is to use the browser default line-height of 1.2 em.
Restrict the number of fonts used and the typographic scale.
Create harmony and rhythm
A type scale does more than just help users move through the copy, it creates harmony and rhythm for the flow of text. This is important on any device.
So where do you start?
UX Matters has some of the best research available on minimum text sizes by device. Note that these are minimum sizes and as body text sizes continue to increase (as does line spacing), you should strongly consider larger point sizes. Steven Hoober recommends starting at least 40 percent larger than the recommended minimums. Further, enhanced content styles can go up to 80 percent above the minimum, but you should be cautious with exceptionally large type as well.
Device Type
Minimum Size
40% Recommendation (adjusted for easy use)
80% Maximum (adjusted for easy use)
Small Phone
4
5.6 (6)
7.2 (7.5)
Large Phone
6
8.4 (8.5)
10.8 (11)
Phablet
7
9.8 (10)
12.6 (13)
Tablet
8
11.2 (11.5)
14.4 (14.5)
Laptop/Desktop
10
14 (14)
18 (18)
Once the body text size is set, you can determine how to size supporting text elements. There’s a fine art to that and the eye test is often a good place to start.
There’s almost no such thing as a headline that’s too big. Say what you need to say and size to scale the words in the space. A two-line headline will feel larger than one-line even if the text is the exact same size.
The easiest way to think about scaling up for headlines and other larger test elements is working in percent based on the body text. While every designer has a different starting point, 250 percent larger than the body text is a good ballpark for the headline; 150 percent for h2, 75 percent for h3 and 50 percent for elements such as block quotes. (This is not a rule, just a starting point.)
Here’s why percents, rather than set sizes, are important: Once you set the size of the body type the percents adjust sizes accordingly regardless of screen size. Every type element is relative to the body type.
Character and spacing guidelines
There are some other guidelines that designers look to as well when it comes to type on the screen. When it comes to spacing, one of the rules of thumb has been to look at characters per line to ensure readability.
Desktop and large devices: 60 to 75 characters per line
Phones and small devices: 35 to 40 characters per line
Note that readability on smaller screens is based on having fewer characters (larger text).
The same idea applies to spacing as well. You need more space between lines of text when the screen size is limited to make it easier for users to read and scan content. Consider adding 25 percent more line spacing on smaller devices than for desktop typography.
The additional size and spacing helps ease that tight or crunched feeling that users can feel when trying to read on smaller devices. Because the canvas is small, reader flow and legibility is vital to keep users scrolling.
Tips to get started
There are plenty of ways to create a typographic scale and ensure that the text does not make your design look fat. How you go about it likely depends on your comfort level with code and development in addition to the design.
The best option is to use a responsive design with media queries. This is the designer-developer option that will provide the greatest level of control over text specifications. (For more go back to those Google recommendations, above.)
Another route is to design different versions. While this is a pretty out-of-date concept, there are still some places using mobile URLs and desktop URLs for their websites. It’s not recommended in most cases, but for some websites where the design is dramatically different or users experience different things, it can be an option.
The easy option is to start with a theme for your website. Just make sure to opt for a fully responsive option. When you use a high quality responsive theme, most of the guesswork is taken out of it for you. All you really have to think about is the body text size. Just make sure to check everything to make sure the mobile type sizes meet your standards.
3 tools to create a type scale
There are a number of tools available to help you see the exact impact of a visual typography scale. Here are a few of the best and most user-friendly options.
Type Scale: Enter text and play with options such as size, scale and font right on the screen; grad the CSS or edit the code right from the tool;
Modular Scale: The scale works like a rule to help determine sizes for type; then download the results as a Sass or JS plugin or see them on the screen;
The right typographic scale will keep your design looking trim and svelte. It is the added harmony that users might not understand but contributes to overall readability and usability.
It’s likely that the scale is off if the design “just doesn’t look right.” Improperly sized type can be tough to pinpoint but is often a place to look when something about a design is out of balance. Play with a few different options for scale before settling on something, and remember the trend right now is for type that’s a bit larger than in the past.
Are you using progressive booting already? What about tree-shaking and code-splitting in React and Angular? Have you set up Brotli or Zopfli compression, OCSP stapling and HPACK compression? Also, how about resource hints, client hints and CSS containment — not to mention IPv6, HTTP/2 and service workers?
Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s config file. Looking back now, things seem to have changed quite significantly.
Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).
So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — a brief overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.
Such a wonderful, useful, and overused font. Don’t get me wrong, it really is amazing. It was actually rated one of the most frequently used fonts of the 20th century and it even has it’s own documentary. But, as a graphic designer, you definitely don’t just want to fall into the flow of things and be like everyone else. You need to have a font that you know people will like, but not to be too mainstream. And that is why today, my friends, I am posting 11 alternative fonts for the modern day designer.
Where did it originate?
So as I was saying, Helvetica was designed and created by Max Miedinger, together with Eduard Hoffmann, in the beautiful year of 1957. I remember it like it was yesterday. It was initially released as Neue Haas Grotesk, designed for the Haas’sche Schriftgiesserei (Haas Type Foundry) in Switzerland. This font, Helvetica, was designed to compete with another font called Akzidenz-Grotesk. As the two competed, Helvetica came out victorious from the gruesome competition and later on became widespread and universally used font of the world!
About It’s Simple and Easy-to-Read Design
While doing some research for this article, I found that there are many derivatives of the font Helvetica. All beautiful in their own way, but my personal favorite is the original. So let’s talk a little bit about the sleek design and unique characteristics of Helvetica.
Instagram should start a new hashtag called #FontCandyFriday, because if that was a thing, this font and design would definitely be featured every Friday. Due to its tall x-height, the font is incredibly legible and relaxing to the eye to read. It has tight spacing between the letters, which makes words appear not too long.
Due to the fact that it is so good and so commonly used, a great and common quote of the modern-day graphic designer would be, “I need a font like Helvetica, but definitely not Helvetica”.
Since everyone and their brother has been posting 10 alternative fonts, I thought to myself, “I’m gonna post 11 because, why not”.
So here you have it: 11 amazing Helvetica alternatives.
Roboto has a dual nature. It has a mechanical skeleton and the forms are largely geometric. At the same time, the font features friendly and open curves. While some grotesks distort their letterforms to force a rigid rhythm, Roboto doesn’t compromise. Thereby allowing letters to be settled into their natural width. This makes for a more natural reading rhythm more commonly found in humanist and serif types.
Aktive Grotesk is a grotesque sans-serif typeface released through Dalton Maag in 2010. It has been described as a “Helvetica killer.” The designers of Aktiv Grotesk wanted to create something in between Helvetica and Univers by removing the quirks from Helvetica and adding a bit of warmth to Univers. Aktiv Grotesk is one of my personal favorite grotesques.
Swiss 721 is a font from Bitstream library. Edouard Hoffmann saw this typeface as an improvement on the late nineteenth century Berthold Gothic, Akzidenz Grotesk. Hoffmann, director of the Haas Typefoundry, specified the design; Max Miedinger drew it under his guidance. It was initially released as the Haas Neue Grotesk; the name Helvetica was applied four years later by Walter Cunz when D. Stempel AG, a major stockholder in Haas. reworked the design for Linotype GmbH in Frankfurt, a major stockholder in Stempel.
Walkway font by this great type designer can be used to make a difference in web design, graphic design or illustration project portfolios. This sans serif typeface comes formatted for graphic design software and publishing software like Adobe Photoshop, Adobe Illustrator, Adobe InDesign, CorelDRAW, QuarkXPress and Microsoft Office and it’s glyphs are compatible with Windows, Mac or Linux operating systems.
The Proxima Nova family is a complete reworking of Proxima Sans (1994). The original six fonts (three weights with italics) have been expanded to 48 full-featured OpenType fonts. There are three widths: Proxima Nova, Proxima Nova Condensed, and Proxima Nova Extra Condensed. Each width consists of 16 fonts—seven weights with matching italics.
Ars Maquette is a grotesque sans-serif typeface designed by Angus R. Shamal and released through ARS Type in 2001. A display version of Ars Maquette is available which is rare for a grotesque font. I think Ars Maquette makes a great alternative to more widely-used sans-serifs such as Proxima Nova or Gotham.
Montserrat evokes the modernist style of the early 20th century, but it feels less formal than, say, Futura. Montserrat comes in 3 variants right now, the original regular version, an alternate caps version and “Subrayada“, which has built in underlining (and which I am not so keen on). The alternate caps are probably more suitable for display being a little wacky, Julia says that they are intended “to capture the variety and soul of Buenos Aires“.
Maison Neue is a grotesque sans-serif typeface designed by Timo Gaessner and released through Milieu Grotesque in 2012. It’s a complete reworking of the original Maison, with updates made to take advantage of new display and reproduction technologies. Maison Neue is available in five weights—light, book, medium, demi and bold—each with matching italics. There is also a nice monospaced version available.
Univers is a classic Swiss neo-grotesque typeface designed by Adrian Frutiger. It was released in 1957, the same year as two other famous neo-grotesques—Folio and Helvetica. The design of Univers is somewhat similar to that of Helvetica, as both were based on the 1896 typeface Akzidenz Grotesk. Univers contains an absolutely huge variety of weights and widths, making it a much more flexible type family than Helvetica.
Galaxie Polaris is a sans-serif typeface designed by Chester Jenkins and published through Constellation in 2004. The Galaxie family, which includes the serif Galaxie Copernicus and script Galaxie Cassiopeia, was designed to be a large, harmonious superfamily. The name Polaris comes from the pole star, as Galaxie Polaris was intended to be a reference point for the design of the rest of the superfamily.
Founders Grotesk is a grotesque sans-serif typeface designed by Kris Sowersby of the New Zealand-based Klim Type Foundry. The design was influenced by classic grotesques from the early twentieth century. The c of Founders Grotesk has a very narrow aperture which is one of its distinguishing characteristics.
So these are our 11 font alternatives for Helvetica. We really hope that you had fun reading this article, and that it was also useful to you in some way, shape, or form. Until next time,
Let’s say you manage a WordPress site. You chose, purchase, and install a pre-made theme. Say you added a few items you came across in the WordPress plugin directory to add some advanced features to the site. This is the awesomeness that is the WordPress ecosystem. It’s relatively easy for anyone with light technical chops to get a website off the ground and wrangle together something powerful without having to build everything from scratch. It just works great and your website looks wonderful.
Until it doesn’t.
I do a little work for a WordPress plugin. The number one thing that gets reported to the support team is, without a doubt, are situations where the plugin conflicts with either the installed theme or another installed plugin. The person reporting the problem has the plugin installed, but what it is doing looks nothing like the screenshots advertised by the plugin.
This can be extremely irritating for the person managing the site. If this plugin is downloaded from the WordPress directory, then it ought to work right out of the box, right?
You could argue this is an unrealistic expectation when you consider that most themes and plugins are developed by different people. It’s understandable that mashing code from multiple authors into the same site will lead to at least some conflicts now and then, despite everyone’s best intentions to deliver good work.
This post is going to look into the specific area of style conflicts and ways to overcome them.
I’ll start off by saying that it’s a tough position being a WordPress theme or plugin developer. On one hand, any stylesheets a plugin includes need to be opinionated enough so that they do what they need to do and look great. On the other hand, they need to respect the work of the active theme and other plugin developers so that the styles play nicely together. It’s a balance that even a trained tightrope walker can appreciate.
We’re not going to talk about the different methods WordPress plugin developers have to make theme and plugin styles more compatible or theme-able. Instead, we’re going to look at the different ways we can override conflicting CSS in WordPress that allow you to take control of the styling for any component of a WordPress site, regardless of whether it originates from the theme or a plugin.
Override Styles in the Active Theme
All WordPress sites employ a theme. CSS-Tricks runs on WordPress and it has its own custom theme, which contains all the template and style files needed to generate this post. Well, assuming you’re reading this on the site and not from a syndicated feed.
The point being that all themes require at least two files, one of which is the magical `style.css`. This file is required because it contains information about the theme that WordPress would be unable to recognize the theme without.
Those of you who know a thing or two about WordPress might want to stop me here because style.css does not have to contain CSS and you would be right. It does not have to and we could simply add our own stylesheet to the header of the theme instead and use style.css as a shell for the theme to be recognized. That’s legit. However, the file was indeed intended to be the primary location of a theme’s files, regardless of how we choose to develop our sites.
If your theme uses the file to contain the theme styles, you can modify it directly to change any of the styling properties of your site. It can also be used to add and override styles that might come packaged in plugins or other third-party sources.
Override Styles in a Child Theme
The active theme method is only great if you are the developer of the theme. Many folks, however, roll with themes made by other developers. I’m sure you’ve seen the many theme marketplaces out there that sell premium WordPress themes that you purchase, download, and install into WordPress. That’s what we’re talking about.
If you’re using one of these themes, then best practice is to manage your customizations in a child theme. This is really a fancy way of describing the process of creating a new folder in your WordPress `wp-content/themes` directory that is the same name as your parent theme, only with `-child` appended to it.
For example, if our parent theme directory is called `css-tricks` then our child theme directory would be called `css-tricks-child`. This directory requires `style.css` just like the parent directory and it will be loaded on the site after the parent theme’s `style.css` file so that any styles contained in the child theme version will override the parent.
Don’t you wish that’s how your teenage years worked?
Now you can make as many changes as needed and you will not lose those changes when installing future updates that the theme developer releases.
Register and Enqueue Your Own Stylesheet
This is one of my favorite ways to go about overriding styles in WordPress. The idea is that you create your own stylesheet and load it into the site theme after all of the other stylesheets so that yours overrides the others.
There are two well-documented WordPress functions, one called wp_register_style() and the other wp_enqueue_style() that allows us to do this and it can be added either to parent or child theme functions.php file in order tell WordPress to look for it and load it in the site header.
This is a basic example of how the function can be used to call a stylesheet by the file name (aka handle) and file path:
function my-custom-styles() {
// Register my custom stylesheet
wp_register_style( 'custom-styles', get_template_directory_uri().'/lib/styles/custom-styles.css' ) );
// Load my custom stylesheet
wp_enqueue_style( 'custom-styles' );
}
add_action( 'wp_enqueue_scripts', 'my-custom-styles' );
We could get a little more fancy by telling WordPress to load it only on a specific page:
// Load my custom stylesheet
function my-custom-styles() {
// Register my custom stylesheet
wp_register_style( 'custom-styles', get_template_directory_uri().'/lib/styles/custom-styles.css' ) );
// Check that the current page is the homepage
if ( is_home ) {
// Then grab the custom stylesheet
wp_enqueue_style( 'custom-styles' );
}
}
add_action( 'wp_enqueue_scripts', 'my-custom-styles' );
Note that adding an extra request to all pages is a performance consideration, but you can certainly wrangle control of that as well.
Art Direction
Art direction seemed to be all the rage in something like 2009, though recent data suggests a slight rebound. The idea being that adding styles to the head on a one-off basis would allow you to create compelling layouts on a post-to-post basis. Styles injected into a block in the head, as long as they come after the regular stylesheets of the site which are probably elements, will have the opportunity to override existing styles nicely.
Art direction can be used as an effective means for overriding conflicting styles as well and is particularly effective when those conflicts only exist in very specific places without having to create and load a full stylesheet to clean things up.
Hey, if a plugin got you into this mess of conflicting styles, then maybe there is one to get you out of it, right? Of course, there is.
I am sure there are others out in the wild, but the one I am most familiar with is Simple Custom CSS. The idea is pretty straightforward: a new screen is added that allows you to write CSS. The CSS entered and saved gets added to the document head which, like the art direction method we discussed, gives you the opportunity to override other styles on that particular page.
WordPress Editor
Oh yeah, remember that? You can actually edit a site’s style.css file directly in WordPress by navigating to the buried tavern that is the Appearance > Editor screen.
I’ll preface this by saying I find this to be a scary place to hang out. It provides you with access to edit the code of any theme file, including PHP templates. The changes are not version controlled, so it’s hard to know what has changed in case you screw something up, and if your version control system is in charge of deployment, and changes there might override changes made here.
Still, it is possible to override styles here and to do so without needing to open up a text editor, saving your changes, then uploading them to a server (via whatever you do for deployment).
Wrapping Up
Look at that: six methods for overriding styles in WordPress. The next time you run into a situation where something does not look right after installing a theme or plugin to your WordPress installation, you now have the power to take control of the mess and clean things up like a boss.
Spark Video, Adobe’s video-storytelling app, just got a huge update. While users have always been able to use Spark Video to create animated videos that feature photos, narration, icons and text, users can now go one step further. They can now add video clips into their creations and projects, and the applications for this are almost endless.
This is part of Adobe’s initiative to respond to the rising demand of video on the web, with some stats predicting that video will represent as much as 80% of global Internet traffic by 2019.
According to a recent release on Adobe’s blog, video clips can be added to a designer’s video project in only a couple of minutes. With this new feature to flesh out video creation on this app, both designers and marketers can harness Video Spark’s platform to engage, connect with, and sell to their audiences more directly with the power of video.
Adobe’s blog post already shows off a slew of video clips that have been created by various companies and personalities with this new feature.
Including video clips was the most-requested feature by users from Video Spark, and the company has given its user base what it wanted.
Using the new feature is both intuitive and easy. Here’s what it involves:
To add a video clip, you simply need to add a slide to your Spark Video projects and then choose a video from your iPad, iPhone or computer. As opposed to working with video editors, the video clip can be grouped into a series of slides of different durations.
Users have the option of making a new point over the same video clip. All they have to do is just break it up into a new slide by selecting the “continue” button. After that, they can just overlay text, an icon, narration, and manipulate the volume.
Designed with the user experience in mind, people can also trim their video clips, so they can customize specifically the points at which the clip starts and ends. Thanks to one-touch trimming, users can do this with only their thumbs.
Of course, what’s a video clip and project without sound? The new feature makes it easy to add voices to the project. All it takes is tapping on the record button and speaking into the mic. Then, users will automatically align their video clips to the specific length of their narrations, all with one tap.
To put the finishing touches on a new video clip, music is essential. Users can add a music track to their clip to provide a general mood to their project. They can add their own tracks or select from the app’s suggestions. There’s also a mini-feature that lets users highlight key moments of sound within the clip to further grab the audience’s attention. Clip sounds can be set as ambient background, muted or emphasized.
Back in 2007, the world met the iPhone for the very first time. After Apple’s product debut, it took less than six months for work to begin on PhoneGap, which would become one of the first and most adopted frameworks for hybrid mobile app development — that is, for apps written simultaneously for multiple platforms using HTML, CSS and JavaScript, rather than coded in native languages.
When compared with the prospect of learning an entirely new language and development environment in order to program iOS (and soon Android) apps, the appeal of this type of development to the already huge population of web developers in the world was palpable.
Back in 2007, the world met the iPhone for the very first time. After Apple’s product debut, it took less than six months for work to begin on PhoneGap, which would become one of the first and most adopted frameworks for hybrid mobile app development — that is, for apps written simultaneously for multiple platforms using HTML, CSS and JavaScript, rather than coded in native languages.
When compared with the prospect of learning an entirely new language and development environment in order to program iOS (and soon Android) apps, the appeal of this type of development to the already huge population of web developers in the world was palpable.
I know this was a lot of definitions, but understanding the basic concept of what a language is comprised of and how to read output values is a key to furthering learning. Most of the concepts above can be transferred to many other programming languages and are pretty universal. Even though we did not get to cover very much code in this section of 
