Native vs HTML5 and Phonegap

This a question that comes up a lot for me. I think about it everyday. I’ve written about it here in the past. The question came up in class yesterday.

Here is a good discussion of the subject:

Some quotes from this article:

Honestly, one big reason developers want to build an app with PhoneGap is so they don’t have to learn Swift or Objective-C. A lot of times, they’re afraid of learning a new language.

Here’s another

great for getting an app out the door quickly…but definitely lacking compared to native.”

(We’ll look at what it’s lacking in a bit…)

But according to Kevin Munc, “dev speed advantages are a myth.”

After learning the new environment, development time is not much improved using using HTML5 vs Native. Essentially you are doing all of the same things, only in another language. It’s learning the other environment that takes time.

Here is another article.

And here are some quotes:

The short answer: yes, using PhoneGap is fine, and will make it easy to build an app without needing to learn additional languages.

While you can deploy apps on multiple platforms, be aware that they won’t perform like native apps in every environment.

One more:

Addendum: Develop twice

One of, if not the biggest, disadvantages of developing native is the fact that you will have to develop two apps, one for iOS, and another for Android. This sounds like a big hurdle if you’re impatient and time and money are the most important factors. But I think are is a hidden advantage to this approach.

Developing first on one platform, allows you to define, refine, and focus your UI and design on one platform before building for the other. Also, there are inherent differences between iOS and Android, building for both, creates an experience that doesn’t truly feel native on either. When quality is important I’m certain native is the choice.

CSS Position Examples

The following series of Codepen examples try to explain the use of absolute and relative position. Visit each of these, read the code, make changes in codepen, and see what happens. Next try and recreate these for yourself.

  1. Static position – This is the default position
  2. Relative position – Relative position offsets an object from where it would have appeared if it has used static position
  3. Relative position with nested objects – What happens to elements inside relatively positioned element?
  4. Absolute position – Absolute position positions an element absolutely
  5. Absolute position – Elements positioned with absolute position can be positioned from their left, top, right, or bottom edges

Screen Shot 2015-06-15 at 1.05.48 is a service that wants to provides a backend for your social media apps. It’s my opinion that Parse is the easiest and fastest way for designers to get into creating social media apps and web sites.

How do we do it now?

The standard method to create a social media app or web site is to create a database and access the database using code written in MySQL. You also need code written in PHP to facilitate transactions with MySQL and manage content from the database. Together this is called the backend. All of these processes happen on a remote computer, your web host.

To have something people can look at you use HTML, CSS, and Javascript. This is called the frontend. You use HTML to structure your web pages, CSS to style them, and javascript to add functionality.

Let’s sum that up. To make a web site that has social media features you need (from front to back):

  • HTMLStructures your data in the browser
  • CSS – Styles the content in the browser
  • Javascript – Adds functionality to the browser
  • PHP – Handles backend services and transactions with the database
  • MySQL – Stores and organizes data provides a service that removes the need for backend programming from the equation. With Parse all of the backend code is handled by the front end. Parse calls itself a: BaaS, which stands for Backend as a Service. The Parse service provides a ready made and hosted backend that can be used to build just about any type of social media app or web site.

Parse saves time by not requiring that you write backend code for creating and configure databases and tables. Parse provides ready made systems for managing user accounts and login. Creating a user login with Parse is as simple as creating the login or sign up form in HTML, CSS, and adding a few lines JavaScript.

For the record, I do not works for Parse and receive nothing from them. As an educator I see Parse as being the easiest way for students to make their social ideas into truly functional apps. For anyone else trying to make their social media ideas into real functioning work, Parse removes many of the roadblocks.

Who would benefit from Parse

Anyone wanting to get started making a social media network would benefit. Parse is well suited to small groups or individuals who want to get started making a social media site. If your skills are more frontend oriented, HTML, CSS, JS, then Parse will save you the trouble of learning PHP, MySQL.

Parse is targeted at startups and small teams looking to create new social media platforms quickly and easily. I see it as a perfect fit for students, as the focus of our students is on front end design and programming. Building an app with Parse moves all of the work of creating a social media app into the front end, and concentrates programming tasks into a smaller set of more familiar tools: HTML, CSS, and JS.

How does Parse work?

In short the Parse service works with Javascript. Essentially you create objects you wish to save in Javascript, and the Parse server takes care of the rest. To display data from the server you request objects from the Parse server through Javascript. Obviously there is a more to it than those two sentences, but not much more.

What kind of things can you make with Parse?

Any social media web site or App. Parse provides libraries code for Xcode, and Android. You can make mobile Application with much less effort, and I’ll say it again, without having to create a backend service, and database. Check out this page of customers using Parse:

Hello Kitty is using Parse! – Scrollview

I really like the look of, I just haven’t had the time to play with it much. I had some time today, and thought I should wait no longer! Having already done the tutorials on the University pages, I thought I’d try and tackle some more practical problems.


When making mobile applications, the scrollview is ubiquitous. This is a UI widget that shows up everywhere and has so many uses. Luckily has a an example in their Starter Kit. Download it from their home page.

The scrollview example is located in reference-examples/views/scrollview.

Take a look at the example itself. The code looks pretty simple, if you’ve gone through the University Tutorials, you should recognize many of the features. Open the example in a browser and test it. Just a set of colored rows with a single line of text. The scrollview doesn’t scroll with a click and drag. It does scroll with a swipe on the track pad. This doesn’t look like it’s doing anything, or is it? Try it in the iOS simulator, or on your mobile device. Here it scrolls with a swipe as expected.

Screen Shot 2014-09-19 at 12.10.43 PM

Take a look at the files in the example folder. There are really two files:

  • index.html
  • src/main.js

Looking at index.html you will see that there is not a whole lot there. There are a few links to js files, that are commented as “Shims for backwards compatibility.” I’ll guess these are not necessary for modern browsers. Then there is a section commented as “famous.” I’ll take a guess that this is the main famous stuff. This section has two style sheets and two js scripts. The first script loads famous from the famous CDN. While the second script loads “src/main.js”, which is the example js.

Take a look at main.js. Overall this is pretty short. The code is wrapped in a define() block. The function passed to define must be called when the rest of the famous and the DOM is loaded. Here require() is used to load modules of the famous code base.

  • Engine
  • Surface
  • Scrollview

After the requires, a context is created, mainContext. The context is the container that renders surfaces.

Next is a new Scrollview object is created.

Then a an empty array, surfaces, is defined. The array is passed to the scrollview object via sequenceFrom().

A note on scrollviews. In general these are set up to display items from a list, or array. The scrollview only displays the rows that are currently visible. If you have a list containing thousands of items, I imagine your iTunes library has thousands of items, your mobile computer does not have enough memory to display all of these as one giant list. Instead the the computer displays only the rows that are currently visible on the screen. I’m guessing Famous is using the same strategy. Hence it needs a list of surfaces to display. The scrollview will mange displaying these surfaces.

Next there is a for loop that builds surfaces and adds them to the surfaces array. Each surface is created with newSurface(). The content of a surface will be the text: “Surface: #”, where # is the number of the surface. The width is undefined, I’ll guess this allows the surface to be any width, and the height is 200 px. Next the surface is assigned properties. The background color, line height, and text align. These are standard CSS properties.

Each new surface was created in a local variable named temp. Next we’re calling the pipe() method and passing a reference to the scrollview. I’m not sure what this doing, I’ll have to revisit the Famous University.

Next push each new surface into the surfaces array.

Last, add the scrollview to the mainContext with add().

What next?

The best way to understand how these things work, and to develop ideas as to how you can use them for your own projects is to experiment! The best way to test these things is to start small. Making small changes and testing to observe the results.

As a start lets work with the content. Line 52 shows:

content: "Surface: " + (i + 1),

This seems to be the content of each row in the scrollview. Let’s play with this and test that assumption. Change the content, try making these changes:

  • Change the text
  • Add HTML tags to format the text

Next change the size of the rows. As is each row 200 px tall, note that the content has a line height 200 px which places the text in the vertical center, and also makes the text take up the whole height of the row.

Change the line height to something more smaller. Add a second line of content to each row.

Try out these properties:

  • fontFamily, fontSize, color
  • border, borderTop

Customize row content

The tableview is not very useful if you can’t customize the content of each row. In the example, rows are generated within a loop, and the only real content is the row number.

Make an array to mock up some more relevant content. The demo uses a loop:

for (var i = 0, temp; i < 40; i++) {

Try replacing this with an array. Define an array and then loop through the array:

var array = ["A", "B", "C", "D"]; // add a lot more, do the whole alphabet
for (var i = 0; i < array.length; i++) {

With this you should see the same rows, but only as many rows as you have elements in the array. Now display the content from the array. Find where the content property is set for the surface. Try this:

content: "Surface: " + array[i] + " " + (i + 1),

At this point you should see something like: “Surface: A 0” for each row. You can use HTML and CSS in here also. Imagine this:

content: "<strong>Surface: " + array[i] + "</strong> " + (i + 1),

Add a class name. You’ll need to style this class in your style sheet.

content: "<strong><span class='title'>Surface:</span> <span class='content'>" + array[i] + "</span></strong> <span class='count'>" + (i + 1) + "</span>",

Watch the quotes carefully. Attribute values must always be in quotes. Since the outer quote is a double “, the inner quotes need to be single ‘.

Adjust the height of the cell.

size: [undefined, 100], // Change the height to 100

The example adds a few properties like:

 properties: {
     backgroundColor: "hsl(" + (i * 360 / 40) + ", 100%, 50%)",
     lineHeight: "200px",
     textAlign: "center"

These these generate CSS properties that are attached to the row element as inline styles. Prove this to yourself. Use the inspector to view one of the scrollview cell rows. You should see something like:

<div class="famous-surface" style="line-height: 200px; text-align: center; opacity: 0.999999; -webkit-transform-origin: 0% 0%; -webkit-transform: matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 200, 0, 1); width: 400px; height: 200px; background-color: rgb(255, 38, 0);">Surface: 2</div>

This shows each row is displayed from a div with a famous class, and some style properties. Some of the properties are applied by famous, while others were added by us when the surface was created.

I think it’s probably better to move our styles to a style sheet. At this point it’s hard to say if this is best practice for Famous. In any regular HTML page it would definitely be best practice.

Note that the color value is generated for each row, the value is based on the row number. It’s this system that gives us the great rainbow effect. For styles that need to be generated on the fly based on data only available when the surface element is created, setting the properties here is a good idea. For general properties, I’m guessing it will better to use a style sheet.







HTML5 is there yet?

Here are some thoughts on HTML5 and whether it’s up to the task of making mobile apps.

Mobile browsers lag, so mobile HTML5 apps suffer

This article from principal HTML5 evangelist at Mozzilla. He says browsers are not up to the task. This is coming from someone at a company that makes browsers. He’s saying the browsers don’t do enough to satisfy the vision that everyone has for HTML5. I have to ask is that a problem of the browser really? Is this a case where someone is saying “hey your browser needs to live up to my vision.”

He also says:

HTML5 is a recognized as a set of standards-based specifications for so-called modern Web applications with multimedia capabilities, leveraging JavaScript and Cascading Style Sheets.

After reading this I had to ask. Is a web browser with multimedia capabilities really the platform to deliver full feature mobile applications?

Here’s another article

Forrester: HTML5 apps still not as good as native apps

Here is a quote:

But adopting HTML5 for mobile apps isn’t a panacea, as reflected in Forrester’s findings. In fact, one of the report’s survey responses noted that 59 percent of the time, apps developed solely using HTML5 took longer to deliver than planned. With non-native responsive frameworks, the greatest amount of time was lost testing and fixing issues.

The survey of developers says 59% of the time HTML5 apps took longer to develop.That flies in the face what people have been touting as common wisdom for the last few years. It seems to fit with my limited personal experience.

Here’s another survey:

Mobile app development: 94% of software developers bet on HTML5 winning

This survey from 2012 says an overwhelming percentage of developers are planning to use HTML5 to build their apps. Their top reason: familiarity with the languages HTML/CSS/JS. I have to ask is that the right reasoning? Admittedly the second most popular reason was cross platform compatibility. You can only imagine that wanting building apps in HTML5 since it is more familiar means that these people do not want to spend time learning a native development tool, and they thought it would be faster and easier. In the article above, from 2014, two years later, shows that a majority of developers agree that it took longer to develop their apps in HTML5. I can imagine that a fair amount of apps took just as long it would have taken to develop native. A few may have been developed faster. But for the majority it was longer or about the same, to develop an app that will lower performance than a native app.

Not sure this looks like it may have come from the same survey above, but doesn’t appear in that article:

Survey: Most Developers Now Prefer HTML5 For Cross-Platform Development

Again here they show 90% of developers using HTML5. I work with students developing apps, and many students want to use HTML5. Many for the reasons popular in the article above, ease and familiarity. I would say a majority of the projects are social media. Notice the chart here labeled types of apps. The most popular app is productivity at 54%, social media apps is 18%.

You could say that social there are fewer people developing social media, and that may be true, it’s hard to say from this chart. Look at games only 8%. Games have to be in the top three for shear volume in apps. Social media apps are also very popular. Looking at the chart in this light, you might start to think that people are choosing native for games and social media. Obviously you can’t make a definitive conclusion like this from this information, but it does hint that there is more to this than the 90% figure.

Also note that the survey was conducted by Telerik kendo UI who develop an HTML5 mobile framework. Some of the questions skew in the favor HTML5 like:

  • Only 15% of the more than 5,000 surveyed would use “Native-only” to target multiple platforms

Targeting multiple platforms with native is native’s biggest disadvantage.

I went out on a limb earlier and said that native apps had better performance. What does that mean?

Americans Prefer Native Mobile Apps Over HTML: Survey

This survey says people prefer native apps. Here’s a quote:

“Smartphone home screens across the country are littered with the tombstones of mediocre, try-once-and-forget apps,” Joseph Farrell, executive vice president of operations at Bite Interactive, said in a statement. “Brands and developers too often lose sight of the most important aspects of developing mobile applications: build in-brand, powerful and highly usable apps that continually deliver real value to your users by solving the problem they have asked you to solve. Delivering continued, iterative and brilliantly executed solutions to those evolving problems should always be the primary objective.”

I think this is a good point. Developing an app faster (or may be not faster) for less, is this a good thing when the user experience is poor? Did you really save time and money? Was your time and money well spent? Maybe not.

From a user perspective native is better. From a developer perspective HTML5 seems to be preferred. Think about that for a moment. Is this the cart driving the horse? shouldn’t a developer want to produce the app that will provide the best experience and performance for a user? Seems like there is little advantage in choosing to develop an app in HTML5 because you are familiar with it, rather than it is the best tool for the job.

But wait, there’s more. Here’s another.

Mobile app developers’ interest in HTML5 is slipping

Here’s an interesting paragraph:

This was the lowest level since Appcelerator began tracking the specification in April 2011. “Interest in HTML5 peaked in July 2012 at 72.7 percent and has shown and uneven but downward slope since,” the report said.

I think this is referring to the same survey that showed HTML5 down to 59%. They mention a downward trend. There isn’t a chart or reference to this, which is too bad. It should be noted, that the survey mentioned here is from Appcelerator, which is a JS based pseudo native app development tool.

Here’s a quote from another source:

In the battle between HTML5 and native apps, HTML5 is starting to become a strong contender. While native app approaches have been a top choice in the past, a recent survey revealed that 57% of participants believe HTML5 is enterprise-ready, or will be in within the next year.

I have been hearing this for a few years now. Note the article was from 2013. We’re in the fourth quarter of 2014, and I think it’s still debatable if HTML5 is “enterprise ready.”

Seems the real advantage to HTML5 for mobile apps is, that it is faster and easier to develop. Keep in mind that the earlier survey said 59% of developers thought it took longer to develop in HTML. Users also prefer native. In this light the advantages of HTML5 seem very slim to nonexistent.

Why post this? I don’t have an axe to grind, but I do feel there is a lot of hype in HTML5 these days. And it’s easy to see it as a good fit for everything. I feel this approach is not the correct approach. Without applying an honest critique to what is happening in the real world you run the risk of choosing a tool that is not the best fit the job. Which leaves you with a poorly performing product and more hassle than necessary. I believe there is a class of app that works well with HTML5, but it’s a small subset of all of the apps you could make. I also believe that the margin in development effort between native HTML5 much slimmer than what most people would suggest, and possibly nonexistent. If there is an advantage to HTML5, it’s in distribution.



Logo as ing or h1

I get this question a lot, here are a few thoughts.

Think about it this way, the alt attribute might tell you what it is if it’s worded well. Bu, even if it is worded well, is it what the page is about? We don’t know. We can’t be sure because the alt is just a description of the the image. The h1 on the other hand is very clearly a very important heading. This is very clear.

Consider a page with these two images:

img alt=”cat”

img alt=”Pepsi”

Is the page about cats or is it about pepsi? You can’t tell. The page might be about Pepsi with a picture of a cat enjoying the pepsi, imagine it’s part of Pepsi’s new ad campaign that takes advantage of the internet’s love of cats.

Or, in an alternate universe, imagine that the page is a cat fancier blog, with a picture their cat named Pepsi. It could happen, Pepsi is a cute name, they already have another cat named Moxi.

Now consider this markup.

h1 Pepsi /h1

img alt cat

The h1 tag clearly says this page is about Pepsi, whether it’s the cat or the drink might have to be determined by meta data. There is no mistaking that Pepsi is more important than cat. Pepsi is a very important heading, while cat is merely an alternate text description of the image.

Using this markup, we’re also clearly describing the content and presentation. Pepsi is the name of the site so we use text. Cat is a picture on the page, presumably a picture of a cat, the computer can’t be sure the picture is actually a Cat, or the logo of a multinational corporation. Consider that in the context of the first example for a moment. Catapillar tractor abbreviates their name as Cat. It’s printed on everything this. I seeing even more room for confusion in the first example.

Using this arrangement we also get the advantage of displaying the logo as text, or as any range of alternate images, based on media queries. The look of the h1 is fully handled by our stylesheet. Mulitnational corporations like to have their logos appear in very specific ways depending on context.

Overly clever readers are thinking, what about this:

img alt=”Cat, the Catapillar company logo”

img alt=”Pepsi our peppy new skid steer loader”

While this is more descriptive it requires a fairly intelligent system to examine the alt text and come up with a meaning. While the Google algorithms are pretty smart, I still feel there’s room for error. And all of the non Google algorithms fail.

Native or HTML5?

Native or HTML5?

Starting a new project, you’re likely to explore what would be the correct platform as a first step. Javascript has a lot of buzz right now. There seems to be a movement to do everything in the Javascript language. At the moment you can Write your app with JS, script your server with Node.js, query your data base in JS using MongoDB. Wow, sounds like you can do it all in JS! This is neat but, I feel it’s important to not lose sight of the forest through the trees. In any project it’s really about choosing the right tool for the job.

If we’re doing everything in JS does that mean the browser is the new OS? I don’t think so. There’s a bit of the emperors new clothes in this type of thinking. The thing about JS and apps in the browser is they just don’t live up the promise in many cases. Or, maybe I should say that there is to much promise. JS has a lot of hiccups and performance issues. Writing a program across HTML, CSS, and JS has a lack of elegance, and feels crude and verbose at times. Just because you can do something doesn’t mean you should. Again it’s about choosing the right tool. The big draw of JS for everything is that it leverages a common tool set, on a common platform. This can save time and money which is good, but if you are making an inferior product is it worth it?

I don’t want to sound like I have some axe to grind. I’ve had a lot of fun with JS, and if it’s the right tool for the job I’m more than happy to use it. My point is HTML5 has so much hype people are treating it like it can do no wrong, like its the wunderkind that can do anything. I just want to get real here. JS can do anything, and I suppose that’s a really a great thing. But, just like people, JS is good at somethings and not good at other things. I’m a firm believer that anyone can do anything if they put their mind to it, I’m not saying that everyone can break world records.

There’s a lot to like about writing code in one place using a common set of tools and deploying to every platform. But if the app provides weak and compromised user experience do you want to put your name on it? Look at Facebook. They had an HTML5 app, and the user experience and performance was weak. The way I see it, they essentially shoehorned a web site into an “app”. They obviously bought into the promise of HTML5.

“The biggest mistake we’ve made as a company was betting on HTML5 over native”

M Zuckerberg

It’s fun to think you can recreate all of the nifty transitions and animation of a native app with JS in a browser. But, you’re not really doing your job unless you apply a critical eye and are willing to say that something is falling short of expectation. Kudos to Facebook for owning up to a problem that was theirs.

Is the browser the new OS? Computers are getting faster, and JS can do more in the browser than ever before. But I don’t think this makes JS the be all end all. There will always be something you can do native that will be out of reach from the browser. Either for security, performance or other reasons. The world may spend more time in a browser than all other apps combined but, I don’t want to edit images in Safari, and I don’t think this is where the world is going.



AngularJS – intro

AngularJS is a Javascript framework from Google. It’s goal is to display data in a web page based on the MVC, and related paradigms. It was built with the idea of being able to make the connections between, data and UI, apparent and easy to manage.

I just began with it a day ago, so take everything here with a grain of salt. I’m sure I’ll cringe at this a month from now. I’m just writing this all down to try and get it all straight in my own head.


Directives are attributes, that act as hooks for AngularJS. Assigning a Directive to a tag creates link to that tag and it’s contents to AngularJS.

AngularJS defines many built in Directives. These all begin with ng-. For example, ng-app, and ng-model. These can, optionally, be prepended with data- for validation if you like. For example: data-ng-app, and data-ng-model.

You can also write your own Directives.

Here area  few Directives.

The ng-app directive tells Angular which part of the page it should manage. It could be placed in the html tag to manage the entire page, or on the body or div tag to manage a smaller realm.

Where this tag is placed determines the document root for Angular. Placing the ng-app directive on a tag other than the <html> tag will limit the scope of the Angular app to that region of the page.

Include an optional module name as a value to this attribute. For example: ng-app=”moduleName”.

The ng-init Directive initializes data. Usually you’ll want to handle this with a Controller.

The ng-controller directive attaches a controller to DOM element. A controller is a Javascript object that will manage data displayed in that region.

The ng-repeat directive tells Angular to copy the elements within the repeat element a number of times. It will populate this “template” element with data from the model.

Loop with ng-repeat

  • {{name}}

Within ng-repeat Angular defines $index, $first, $middle, and $last. $index holds the the index of the repeated element. While $first, $middle and $last are booleans, true when the element is the first, middle or last element.


The {{}} defines a template expression. The {{ and }} can thought of as defining the area where Angular will write data. The expression inside can be thought of as modifying or defining how the data is written.

The ng-model attribute allows you to define connection from the DOM to model data. In the case of an input field modifying the input modifies the model data directly.

{{item.price | currency}}

The | defines a filter to be applied to the content of a {{}} template. There are several built in templates, and you can define your own. The example above formats item.price as currency.

The ng-click directive sets up a click action that will call on JS we define. The handler function should be part of the $scope of the controller that contains this ng-click.

Note that $index is a variable defined by ng-repeat.


The ng-bind attribute can be used to bind a view element to a model value. This works the same as use the {{}} template syntax. Where the {{}} syntax will show the {{}} for a moment when the page initially loads the ng-bind directive will not. Making this good for elements that will show initially.

Use ng-change to call a function defined in the $scope of the elements controller when a form element changes.

Use ng-submit to call a function when a form is submitted.

some text

Images and Anchors are special cases and have their own specific directives.

MVC – Model View Controller

MVC is a software design pattern that breaks functionality into three areas: Model, View, and Controller. This pattern is particularly suited to software that handles and manipulates data via user interface. Which makes it a good fit for Web apps. AngularJS turns HTML, CSS, and Javascript into a surprisingly good fit for this pattern.


Angular uses the MVC, or Model, View, Controller, paradigm. Where the Model represents data used by your program. For example, a list of user names, or a list of products with their price and description. The View is where data is displayed and represents the visual end of your program. The controller is the business side of your program. It contains the logic that manages data and facilitates translating data so it can be displayed by the View.

A Model can be as simple as a variable containing the number of times a button has been clicked. More often model data will be an array or object containing a list of values and properties.

A Controller might contain functions that controls the how a number is displayed. It might round the value off or format it any number of ways. More often the Controller will load an array of data and sort and filter before sending it to the View.

Views in Angular, are HTML. The view is essentially written in HTML and CSS, along with Angular’s templating system. Controllers are tied to views directly in the HTML as attribute names. This is a key feature of Angular that makes it unique.


Controllers handle processing model data.


The display data held by the model. Views in AngularJS are templates defined as snippets of HTML. These can be external files loaded into the app, or defined within the same file tags. Templates can all be defined as strings as part of a controller, directive or other module.


Model data should be defined in a “modules”. Use Angular’s module method to create a new module.


Services are singleton objects that provide global functionality to an app. Built in services begin with the $, such as $routeProvider, and $http.


Here’s the outline for an Angular page: