Follow our latest news

Retail

Taqtile Signs Leading Brazilian Retailer as Mobile Platform Customer

14July

Extra

You know you are doing something right when one of the largest retailers in Latin America invites you to a unique partnership that involves working hand-in-hand to design their mobile omnichannel strategy, a strategy that will form the basis of their entire e- and m-commerce platform for the foreseeable future.

The partnership between Taqtile and Nova Pontocom, which was announced in July 2013, kicked off with the design and construction of the Extra.com mobile site, and by the end of the year will result in the launching of mobile sites, smartphone and tablet applications for 3 brands of the group, Extra, Ponto Frio and Casas Bahia.

While Taqtile’s development and maintenance teams work closely with Nova Pontocom’s IT team on the m-commerce front, the Taqtile creative team works closely with the retailer’s marketing group in the process of designing and prototyping new applications focused on amazing customer experiences and omnichannel enabling features.

Innovations are not limited to conception of new applications; Nova Pontocom gives Taqtile a great deal of freedom to work with new technology trends, and the results are starting to be seen by the end customer. An example of this is the aforementioned customer-facing mobile site, Extra.com, which was developed with Backbone.js, providing both a high-performance and a high-fidelity experience for its users. On the server side, Taqtile’s enhanced middleware is fully integrated with the Novo’s existing e-commerce infrastructure, thereby having zero impact on the retailer’s complex business rules and processes.

About Nova Pontocom
Nova Pontocom is the digital arm of Pão de Açúcar Group, the largest retailer in Brazil, with more than 1.600 stores and annual net sales revenue of more than USD 20 bi (USD 1.8 bi of them just online).

, , , , , ,
Retail

Dollar General breaks new ground in the dollar store category with rich mobile shopping app.

14July

Dollar General

Dollar General is the largest dollar store chain in the United States with more than 11,000 stores, and is growing at a pace of almost 1000 stores a year. In addition to leading the way in many innovations in the dollar store category, Dollar General is leading the segment in consumer-enabling technology and was the first dollar store to launch a fully-functional suite of native mobile applications for iOS and Android.

Dollar General launched these apps just prior to the 2012 Holiday Season with a great set of initial features that includes sales ads, store locations, coupons and more, giving shoppers access to Dollar General anytime, anywhere in the palm of their hand.

Many Dollar General shoppers use mobile phones for shopping and to make purchasing decisions and the mobile apps make simpler for their customers by making ads and information available at the touch of a button on their mobile phone, wherever they are, whenever they want it.

Dollar General’s app allows customers to:

  • Find stores with a store locator.
  • View ads, create shopping lists and share via email or text message.
  • Save money with mobile coupons.
  • Use free Quick Response (QR) scanner to access upcoming sales and unlock additional savings.
  • Connect with Dollar General through Facebook, YouTube and Twitter.

Consumers who download the application will be the first to learn about upcoming sales and can take advantage of special discounts and coupons that will be available on the DG mobile app and DG’s mobile site.

The Dollar General application is currently available for free in most popular smart phone application markets.

Download it now on App Store or Google Play.

, , , , , ,
Retail

Hy-Vee creates award-winning mobile experience with Taqtile Retail 1.0

14July

Hy-vee app

The problem:
Hy-Vee is a company that puts a premium on customer service, said Ryan Neville, director of Internet and new media. The company saw industry trends calling for mobile apps to better keep up with what customers wanted.

The innovation:
Hy-Vee launched a mobile app, to which it continues to add features. To manage its social media campaign, it installed a customer care center “war room,” where employees respond to customer tweets, Facebook posts, emails and phone calls to provide as much real-time service as possible.

How they did it:
It almost sounds too simple.

A grocery store has customers. Those customers want to have a positive shopping experience. For most of Hy-Vee’s 80 years in business, it has focused on store employees helping customers – the “helpful smile in every aisle.”

Technology now provides another way to help customers.

“When we think innovation, I think a lot of people think of it as creating the next iPad or something,” Neville said. “A lot of our digital initiatives, it’s not really something completely new. It’s taking something that we’ve done for years and years and doing it just a little bit different or doing it a little bit better.”

In 2011, Hy-Vee corporate leaders saw a mobile app as a necessity. With Heather Mitchell, mobile and social media specialist, leading the way, the company launched a basic app and has continued to add features to it.

The app can locate a product in any one of the company’s stores, make shopping lists, and refill pharmacy prescriptions. Soon, Hy-Vee app users will be able to coordinate their shopping list between their desktop computers, smartphones and tablets.

“People are on the go,” said Mitchell. “They have their mobile devices with them all the time, so it’s just kind of fitting a need. That’s where (our customers) are at, and that’s where we need to be too.”

At the same time, Hy-Vee has put an extra emphasis on customer service through social media.

The company’s West Des Moines corporate office features the customer care center, sometimes referred to as the “war room,” with eight television monitors mounted on the wall and the day’s headlines scrolling on a news ticker. The room has representatives taking phone calls, checking emails, and monitoring social media websites to deal with customer service issues.

The goal is to be able to have store representatives answer customer social media complaints on the spot. They aren’t quite there, but they’re getting there, Neville said.

The payoff:
The mobile app has gained more than 150,000 users with little marketing effort. It recently won a Prometheus Award from the Technology Association of Iowa for the best mobile application. Employees in the customer care center respond to about 150 emails and 1,500 social media mentions a week.

Taken From: Business Record

The Hy-Vee application is currently available for free in most popular smart phone application markets.

Download it now on App Store or Google Play.

, , , , , ,
Technology

Core Data over SQLite Performance Tests – Part 3

03June

Following the last post, Core Data over SQLite Performance Tests – Part 2, when we began performance tests with Core Data, now we continue with the results of this analysis.

As we defined before, this test will show the performance of 4 situations (see details on the previous post):

  1. Insert without join tables;
  2. Inserts with tables;
  3. Select without join tables;
  4. Select with join tables.

The previous post showed the first 2 situations. This time we will cover the last 2 (selects).

1. Select without join tables

This test tries to execute selects without joins in 2 ways:

  • Fetch by object’s attributes;
  • Fetch by identifier.

In each case, we see how the time to execute the select varies with the number of registries of the table (from 1 to 10000):

a) Fetch by object’s attributes

min 0.007469 s
max 0.259504 s
average 0.049227 s
total 492.3 s

As we can see on the chart, when fetching by an attribute that is not indexed the time needed to execute the select varies almost linearly with the number of registries of the table. So, it is easy to think on how the performance of your table is getting worst with the time.

b) Fetch by identifier

min 0.000070 s
max 0.004420 s
average 0.000086 s
total 0.8597 s

This case shown us that fetching by the identifier (indexed), the time to fetch almost do not change with the number of registries, once the average time to fetch was almost equal the min time.

Conclusion

This tests resulted on the following table:

Test Average Time per Select Total Time
Fetch by object’s attributes t1 or 0.049227 s t2 or 492.3 s
Fetch by identifier 0.0017 x t1 or 0.000086 s 0.0017 x t2 or 0.8597 s

As we can see, for simple selects (without joins) when possible we should use identifiers to fetch, but, if we need to fetch by an attribute, it’s not hard to think about the performance, once it increases linearly with the size of the table.

2. Selects with join tables

This test shows how the time to execute a select increases as the number of join tables (in each select) and number of rows increases. The number of joins varies from 0 to 4.

a) Joins quantity: 0

min 0.010763 s
max 0.405039 s
average 0.071537 s
total 7.15 s

This test has no joins, so the results is the same from the previous test when fetching by an attribute.

b) Joins quantity: 1

min 0.012153 s
max 0.632435 s
average 0.299673 s
total 29.98 s

As might be expected, with 1 join the average time to a insert was much worst, about 4.27 times greater than with 0 joins.

c) Joins quantity: 2

min 0.021038 s
max 0.633293 s
average 0.29986 s
total 29.96 s

With 2 joins we needed almost the same time to process the select, as expected, once the fetching engine has already entered on the process’ join step, what is not needed with 0 joins.

d) Joins quantity: 3

min 0.025723 s
max 0.621014 s
average 0.303619 s
total 30.36 s

With 3 joins the average time was slightly worst again, as we might expect.

e) Joins quantity: 4

min 0.027883 s
max 0.64675 s
average 0.316077 s
total 31.61 s

Again, with 4 joins the average time was slightly worst, as we might expect.

Conclusion

The following table results from the tests:

Test Average Time Total Time
0 joins 0.071537 s 7.15 s
1 join 0.299673 s 29.98 s
2 joins 0.29986 s 29.96 s
3 joins 0.303619 s 30.36 s
4 joins 0.316077 s 31.61 s

As we can see, we have a great variance from 0 to 1 join, but a small variance as the number of joins increases, due the way the select engine works.

This post, and the previous one, showed performance tests for Core Data that bring us information to analyse when use it in a project and what impact we would have when using it.

Technology

Core Data over SQLite Performance Tests – Part 2

03June

Following the last post, Core Data over SQLite Performance Tests – Part 1, when we introduced Core Data and defined the environment in which tests will run on, now we are going to start presenting you the results of this analysis.

As we defined before, this test will show the performance of 4 situations (see details on the previous post):

  1. Insert without join tables;
  2. Inserts with tables;
  3. Select without join tables;
  4. Select with join tables.

This post will cover the first 2 situations (inserts).

1. Inserts without join tables

This test tries to execute 10000 inserts on 5 different ways:

  • Batch size: 1; Times: 10000;
  • Batch size: 10; Times: 1000;
  • Batch size: 100; Times: 100;
  • Batch size: 1000; Times: 10;
  • Batch size: 10000; Times: 1.

The results were the following:

a) Batch size: 1; Times: 10000

min 0.037017 s
max 0.571604 s
average 0.047213 s
total 417.3 s

As we can see on the chart, we have a slight variance between the inserts. Although the maximum chart value was 0.57 seconds, the average (0.047s) was much more close to the minimum value (0.037s). Also, we can see that the time needed to a insert does not changes significantly while the table increases.

b) Batch size: 10; Times: 1000

min 0.051545 s
max 1.592167 s
average 0.077328 s
total 77.3 s

This case shown us that, increasing the batch size to 10 we need, on average, about 1.64x more time to execute this batch. So, we can imagine that is much better to execute a big batch than lot of small batches. The test shown that to insert 10000 registries with batch size of 10 we needed 77.3 s, while with batch size of 1, to insert 10000 registries we needed 417.3 s.

c) Batch size: 100; Times: 100

min 0.221817 s
max 0.733436 s
average 0.276504 s
total 27.7 s

This case shown that increasing again the batch size, now to 100, we needed about 3.6x more time per batch than we needed with batch size of 10. So, we can deduce that the time per batch does not increases linearly as the batch size increases. But again, the total time to execute 10000 inserts was lower (27 s against 77 s).

d) Batch size: 1000; Times: 10

min 2.341496 s
max 2.895445 s
average 2.522845 s
total 25.2 s

Again, the same happened. As we increases the batch size to 1000 we needed 9.1x more time than we needed with batch size of 100. The total time was better than the previous, but is almost the same (25 s against 27 s).

e) Batch size: 10000; Times: 1 (10 repetitions with empty database)

min 19.171194 s
max 24.020913 s
average 22.2 s

This time, increasing the batch size to 10000 we needed 8x more time than we needed with batch size of 1000, while we could imagine we would need more than 9.1. So, we needed only 22 s to execute 10000 inserts.

Conclusion

This tests resulted on the following table:

Test Average Time per Batch Total Time
a t1 or 0.047213 s t2 or 417.3 s
b 1.83 x t1 or 0.077328 s t2/5.40 or 77.3 s
c 5.86 x t1 or 0.276504 s t2/0.066 or 27.7 s
d 53.68 x t1 or 2.523 s t2/0.060 or 25.2 s
e 470.34 x t1 or 22.2 s t2/0.053 or 22.2 s

As we can see, for simple inserts (without joins) as we increases the batch size, the time needed to to execute that batch is greater, but, the total time is lower. So, with Core Data, when possible we should save data to database using batches.

2. Inserts with join tables

This test shows how the time to execute a insert increases as the number of join tables (in each insert) and number of rows increases. The number of joins varies from 0 to 3.

a) Joins quantity: 0

min 0.053622 s
max 0.626013 s
average 0.068631 s
total 137.3 s

This test has no joins, so the results is the same from the previous test.

b) Joins quantity: 1

min 0.617910 s
max 0.353416 s
average 0.080156 s
total 160.3 s

As might be expected, with 1 join the average time to a insert was 1.17 times greater than with 0 joins.

c) Joins quantity: 2

min 0.078214 s
max 0.559592 s
average 0.109143 s
total 218.3 s

With 2 joins we needed even more time to process an insert: 1.37 times more than with 1 join. Also, we can see that it seems that, as the database increases, we need more time to do inserts that was join tables.

d) Joins quantity: 3

min 0.093524 s
max 0.650233 s
average 0.135843 s
total 271.7 s

With 3 joins the average time was worst again: 1.244 times more than with 2 joins.

Conclusion

The following table results from the tests:

Test Average Time Total Time
a t1 or 0.068631 s t2 or 137.3 s
b 1.17 x t1 or 0.080156 s 1.17 x t2 or 160.3 s
c 1.59 x t1 or 0.109143 s 1.59 x t2 or 218.3 s
d 1.99 x t1 or 0.135843 s 1.99 x t2 or 271.7 s

As we can see, as the number of joins increases in a insert the time required to process it also increases. This increasing number is not linear.

The next post will present our results and conclusions for selects on Core Data, stay tuned!

 

Technology

Core Data over SQLite Performance Tests – Part 1

03June

Following the last post, iPhone Persistent Store Overview, Taqtile begins the performance experiments series, on iPhone persistent store alternatives, with Core Data, Apple’s official framework for this purpose.

Introduction

Core Data for iPhone was introduced in the 3.0 version of the SDK, although it was previously available for Mac OSX. The framework implements an Object Graph Manager, giving applications the ability to manage data, including inserting new records, applying changes, undoing and redoing them and also the ability persist them.
It provides a high level API that abstracts all data management rules, as unique identifiers, model consistency and data validation, insertion, update and deletion, as well as data store creation and operation.

Data modeling abstraction is achieved by Xcode’s integrated graphical data modeling tool, where  the developer must describe an entity-relationship diagram representing and the system’s data. Xcode then generates all the classes and files needed to manage and optionally persist the data.

The persistent store layer abstracts the database and file store to the developer. The iPhone SDK provides SQLite and a binary format and the Mac OSX SDK also provides XML persistence. Either way, the implementation details stay apart from the developer, who should only care about objects and its properties.

Core Data Architecture

To implement the previously described functionality, a flexible and solid architecture was created, as seen in the following diagram:

Core Data Architecture

  • NSManagedObjectModel: Created on run-time, based on the project’s data model, which is designed by the developer in the integrated graphical tool, represents the hole system’s data;
  • NSManagedObject: Represents each entity and its properties, modeled by the developer. Those properties includes attributes and relationships;
  • NSManagedObjectContext: Provides all the mentioned functionality to the Managed Objects, as fetching and deletion; It is aware of and has access to the Persistent Store Coordinator;
  • NSPersistentStoreCoordinator: Provides an interface to the data persistence layer.

As mentioned before, Core Data is not limited to data persistence. All aspects of data management are separated from the persistence layer and can be used without it.

Testing Methodology

Environment

iPhone 3G 8GB Xcode 3.2.3 iPhone SDK 4.0 iOS 4.0 Release Configuration

Data Model

 

 

Testing Scenario

SQLite was chosen over binary format because it is the only type that is capable of partial object graph loading, making use of the lazy fetching feature, what is very important for the powerful, though limited iPhone hardware capabilities.

Also, a 10000 lines database, or 10000 persistent objects, was considered enough for performance testing purpose. Core Data persists its objects by saving all the NSManagedObjects present in the NSManagedObjectContext by once. Therefore, the testing methodology for the insertion tests included batch operations, with different of objects quantity per save, as the following table describes:

Batch size Times
1 10000
10 1000
100 100
1000 10
10000 1

The following testes will be performed:

  1. Insert without join tables
    The main objective of this test is to determine the insertion performance degradation, according to the database size. Therefore, following the previous ta ble, 10000 objects will be persisted.
  2. Insert with join tables
    This test purpose is to decide how much the number of table joins affect the performance. Therefore, a smaller database will be used (2000 lines) with join quantity from none to four.
  3. Select without join tables
    In this test two approaches will be considered: fetching objects by its attributes and getting them by their identifier. The performance is going to be measured, until the persisted object’s count reaches 10000.
  4. Select with join tables
    This tests aims to identify the selection performance degradation, according to the number of object relationships (table joins). Since this is the heaviest test, once the data must be inserted and then selected accordingly, data will be selected after each 100 objects are inserted (atomically).

All tests have as main objective to determine the performance degradation of Core Data in relation to the amount of persisted data and the number of relationships between the data entities.

The next post will present our results and conclusions, stay tuned!

 

Technology

iPhone Persistent Store Overview

03June

Storing information over iPhone apps is a task that needs to be carefully taken and analyzed. We know an iPhone has limited resources that need to be used and released, properly. The problem is: what happens when you have an app that stores and load large amount of data (e.g, a Sales Force Automation Applications)?

We don’t know how the application will respond to these data access with the time (as the database size increases). Moreover, we have lot of third-party options of persistence layer, or layers responsible to manage data access and data mapping to objects.

These third-party options may have other problems that could resulting in performance loss with the time. So, choosing the best for each situation isn’t an easy job.

Thus, I.ndigo has decided to begin a series of performance experiments on the most known options of Persistent Store, and obviously, the Core Data purely implemented.

Searching on the web for options resulted on the following list of technologies:

Core Data FMDB Magical Panda Mogenerator OmniDataObjects iphone-rsdb SQLite SQLitePersistentObjects
Abstraction level object graph manager SQLite wrapper ActiveRecord (over Core Data) object graph manager Core Data API implementation (over SQLite) SQLite wrapper (based on fmdb) - ActiveRecord over SQLite
belongs_to implementation yes yes yes yes yes yes yes yes
has_many implementation yes yes yes yes yes yes yes yes
many_to_many implementation yes yes yes yes N/A no yes no
SQL no yes no no no yes yes yes
Lazy Loading yes no yes yes yes no yes no
License iPhone Program MIT MIT N/A MIT Apache 2.0 Public Domain New BSD License
This table also shows information about these technologies, which helped us to choose different options to test and compare one another. This table also shows whether there is any license limitation or need for a specific tool, such as SQL implementation.Next posts will cover a serie of tests executed on some of these technologies and comparisons between them in several scenarios.Stay tuned!

Infographics

Taqtile 2011 Infographic

25January

Our fantastic and obviously not busy enough designers have done a summary of our year in 2011. Unbelievable year. Thanks to everyone! Looking forward to 2012!

News

Hy-Vee Television Coverage

15December

This local news channel picked up on the Hy-Vee App launch. Great story… http://www.kwwl.com/story/16230843/hy-vee-introduces-shopping-app

Random Notes

Royal Wedding Aftermath

16June

So, we were completely under wraps and feeding ourselves from a tube to launch the NBC Royal Wedding App on time for the big event on April 27th. It was a huge success with over 250,000 downloads of the app on iPad, iPhone and Android platforms. The event was probably THE major media event of 2011 and high interest continues on the app even today. Check it out at the iTunes App Store.