‘SoundWear’ a heads-up sound augmentation gadget helps expand children’s play experience

In this digital era, there has been growing concern that children spend most of their playtime watching TV, playing computer games, and staring at mobile phones with ‘head-down’ posture even outdoors.

To counter such concerns, KAIST researchers designed a wearable bracelet using sound augmentation to leverage play benefits by employing digital technology. The research team also investigated how sound influences children’s play experiences according to their physical, social, and imaginative aspects.

Playing is a large part of enjoyable and rewarding lives, especially for children. Previously, a large part of children’s playtime used to take place outdoors, and playing outdoors has long been praised for playing an essential role in providing opportunities to perform physical activity, improve social skills, and boost imaginative thinking.

Motivated by these concerns, a KAIST research team led by Professor Woohun Lee and his researcher Jiwoo Hong from the Department of Industrial Design made use of sound augmentation, which is beneficial for motivating playful experiences by facilitating imagination and enhancing social awareness with its ambient and omnidirectional characteristics.

Despite the beneficial characteristics of sound augmentation, only a few studies have explored sound interaction as a technology to augment outdoor play due to its abstractness when conveying information in an open space outdoors. There is also a lack of empirical evidence regarding its effect on children’s play experiences.

Professor Lee’s team designed and implemented an original bracelet-type wearable device called SoundWear. This device uses non-speech sound as a core digital feature for children to broaden their imaginations and improvise their outdoor games.

Children equipped with SoundWear were allowed to explore multiple sounds (i.e., everyday and instrumental sounds) on SoundPalette, pick a desired sound, generate the sound with a swinging movement, and transfer the sound between multiple devices for their outdoor play.

Both the quantitative and qualitative results of a user study indicated that augmenting playtime with everyday sounds triggered children’s imagination and resulted in distinct play behaviors, whereas instrumental sounds were transparently integrated with existing outdoor games while fully preserving play benefits in physical, social, and imaginative ways.

The team also found that the gestural interaction of SoundWear and the free sound choice on SoundPalette helped children to gain a sense of achievement and ownership toward sound. This led children to be physically and socially active while playing.

PhD candidate Hong said, “Our work can encourage the discussion on using digital technology that entails sound augmentation and gestural interactions for understanding and cultivating creative improvisations, social pretenses, and ownership of digital materials in digitally augmented play experiences.”

Professor Lee also envisioned that the findings being helpful to parents and educators saying, “I hope the verified effect of digital technology on children’s play informs parents and educators to help them make more informed decisions and incorporate the playful and creative usage of new media, such as mobile phones and smart toys, for young children.”

This research titled “SoundWear: Effect of Non-speech Sound Augmentation on the Outdoor Play Experience of Children” was presented at DIS 2020 (the ACM Conference on Designing Interactive Systems) taking place virtually in Eindhoven, Netherlands, from July 6 to 20. This work received an Honorable Mention Award for being in the top 5% of all the submissions to the conference.

Go to Source


Why API Gateways Still Matter in Service Mesh Deployments

Most of the organizations have become brave enough and spend a lot of time on R&D to convert their underlying business infrastructure to match with the next generation. Most of the time people are focusing on totally revamping their architecture by choosing to go with a microservices model, leaving behind their monolithic architecture. Even though this has been the trend, organizations find it difficult to take this leap, as it would require some specific set of knowledge and technologies, and their architects and IT employees need time to become experts of these novel ideas.

Having expertise in implementing microservice architecture (MSA) and studying different technologies that provide the capability gives you another set of problems when actually trying to design your architecture. I will try to discuss a few of these problems here. First I will try to explain the transition from monolith to microservices.


In the most common cases of monolithic architecture, there will be a single application that provides the business capability, and any scaling of that application can be done as a whole based on the demand. When certain types of governance are required and the business functionality can be abstracted with APIs (as the organization moves to modernize its legacy IT), API gateways can take over the role of requirements like security, authorization, rate limiting, and transformations from the different business components.

Transform to Microservices

One of the initial steps in the journey of moving towards an MSA is to break down the monolith application into smaller services each of which handles specific business logic. The services are loosely coupled with each other and communicate with each other using typical API calls over the network based on HTTP, gRPC, etc.

But microservice sprawl can lead to another problem; their management and governance. The challenges include but are not limited to:

  1. Monitoring the microservices for their health, metrics and logs
  2. Hot deploying a microservice with a bug fix (so as not to disrupt the other services that depend on it)
  3. Adding new microservices and handling the routing for them
  4. Securing service to service communication and handling security in a standard manner across all services
  5. Managing the traffic with circuit breaking, timeouts and rate limiting
  6. Adding new policies to govern the microservices and manage those policies

One proven way of dealing with these and other challenges raised by microservice expansion is to build a service mesh by adopting a service mesh solution provider. 

A service mesh is a network of microservices that, when taken together, form the basis of a  composable  application. A service mesh provides infrastructure to handle the interaction between those microservices. It consists of a data plane which is the mesh of microservices and a control plane that governs and manages the data plane.  A service mesh injects a proxy as a sidecar to each microservice. This sidecar proxy governs how microservices communicate with each other and how the control plane communicates with the sidecar proxy in order to manage the data plane. 

Deploying a service mesh adds a new set of questions at the architectural level. The main problem is where do I put my good old API gateway in the service mesh or if I even need one. Do API gateways and service meshes solve the same set of problems. For example:

  • A service mesh provides secure service to service communication. Do I need API gateway security any more?
  • A service mesh provides request authentication and identifies the client. Do I still need the API gateway for end-user authentication?
  • A service mesh provides circuit breaking, timeouts and pluggable policies. Do I need the same features from the API gateway?
  • A service mesh also handles the traffic routing within the mesh. Why do I need API gateway routing anymore?
  • A service mesh provides metrics and logging about the included microservices. Why do I need an API gateway for monitoring and analytics?

On the surface, it appears as though API gateways and service meshes solve the same problem and are therefore redundant. Actually they do solve the same problems, but in two completely different contexts. Mainly an API gateway acts in the edge of the deployment facing the external clients, handling north south traffic and service mesh manages the traffic among the different microservices which is the east west traffic.

Let’s try to break down the above statement under different facts.

1. APIs vs Microservices

The basic idea of a service mesh is to provide an ecosystem to manage the microservices. Ultimately however, the end-to-end business functionality (eg: the workflow to place an order) is a set of interfaces defined as APIs for external parties and developers to consume. In other words, the API is an abstraction of a workflow consisting of multiple microservices that, when stitched together, performs a meaningful business operation. The service mesh controls those microservices which are behind the API while the API is a digital asset that’s discoverable by external/internal parties at the edge of your deployment. To govern these APIs and to manage them and act as a policy enforcement point (PEP) for externally discoverable APIs, the overall deployment therefore requires an API gateway at the edge.

2. Security

A typical service mesh would provide different mechanisms to secure the service to service communication or the east-west traffic of the deployment. The most common way seems to be the mutual transport layer security (TLS). So the services can communicate with a set of trusted services only. One of the main capabilities of the service mesh is to manage the certificates required for mutual TLS within the mesh, as the services are updated frequently. A service mesh handles these capabilities via its own control plane by rotating the certificates. When a new microservice is deployed or existing certificates expire, the control plane updates all the other microservices by distributing newly added microservices’s public certificate with other microservices. This helps to hot deploy new services within the mesh while maintaining secure mutual transport layer security.

But once these microservices are exposed as APIs to the external parties, there should be a way to authenticate the external parties consuming these APIs. Authenticating north south traffic is more serious because it’s coming from unknown external parties. API gateways are specifically designed for this purpose, to act at the edge and stop unauthenticated or untrusted traffic from coming into the system. 
So API gateways provide stronger end user security mechanisms like Oauth2 and OIDC flows that are designed to identify and authenticate the actual end users of these microservices. Once the API gateway authenticates the north south traffic, the service mesh handles the service to service communication with its own internal security mechanisms like mutual TLS.  

A service mesh can provide authorization capabilities as well. The ability to define custom authorization policies are another key feature of a service mesh. But these policies are actually a set of rules that governs the traffic within the mesh. For example allow traffic from a certain IP address, allow the traffic for certain HTTP paths (eg: :/order/{id}) only, etc. These policies do not focus on end user privileges like their roles or permissions. But API gateways provide more end user authorization capabilities with mechanisms like role-based and permission-based authorization checks using fine grained access mechanisms like scope, XACML or via connecting with policy agents.

3. Traffic management

Traffic management is another common functionality provided by the API gateway as well as by a service mesh provider. Service mesh implementations provide capabilities like connection timeouts, circuit breaking, and request retrying when connecting with microservices. API gateways also provide the same set of capabilities when connecting with microservices. 

Where they differ is in the nature of configurable traffic policies. In a service mesh, the rate limiting policies can be applied at the microservice level. We can limit the allowed number of requests or the request bandwidth (bytes per second) for a particular microservice using a service mesh. An API gateway however allows you to define more complex traffic policies based on the end user. It can limit the access to APIs for certain sets of users under different rate limit policies. Such end user based traffic limiting capabilities can be integrated with billing engines in order to monetize the APIs as well. An API gateway can also apply traffic policies to meaningful APIs that provide a particular business capability rather than applying them at microservice level. These capabilities of API gateways make it possible to block a user from using an API. On the other hand, these kinds of traffic management requirements would be difficult to achieve with the capabilities provided by a service mesh. 

4. Traffic routing

API gateways and service meshes both have their own dynamic routing tables for routing requests to the correct endpoint or microservice. A service mesh does routing at two levels. First, routing at the ingress level (ingress gateway) to route traffic to the correct side car or microservice and second, within the sidecar proxy to route traffic for service to service communication. 

The API gateway engages at the ingress level in the service mesh, and can act as the first layer of routing rather than using an ingress gateway. So an API gateway is perfectly suited to handling the ingress traffic thereby replacing the ingress gateway of a service mesh allowing only secure traffic to the mesh.

5. Monitoring tools

API gateways and service mesh implementations focus on monitoring tools, but they are intended for two different purposes. Service meshes provide metrics related to microservices where each side car publishes data related to latency, resource utilization, and the throughput of each microservice that is attached to the sidecar. This data is helpful for devops personnel whose job it is to identify issues within the service mesh, and enables them to isolate issues. 

On the other hand, an API gateway monitors the traffic at the ingress level and provides valuable insights regarding the usage of APIs. Examples of this data include which API has the most frequent hits, from which geographical area the most frequent users are coming, which set of users are the most frequent visitors, how many API calls were successful, and how many calls failed. So these kinds of data can be used for analytical purposes to design future improvements of the platform. They can also give an idea of how much of revenue is generated and how much revenue is lost due to faulty invocations as well.

The above diagram explains how an API gateway fits into a service mesh at the edge of your deployment. So it’s a bad idea to consider these two as competitors just by looking at the features of each. It’s better to view the two as being complementary to one another in deployments that involve both microservices and APIs. 

Go to Source
Author: <a href="">rajithk90</a>


Overall time on social media is not related to teen anxiety and depression

The amount of time teenagers spend on social networking sites has risen 62.5 percent since 2012 and continues to grow. Just last year, the average time teenagers spent on social media was estimated as 2.6 hours per day. Critics have claimed that more screen time is increasing depression and anxiety in teenagers.

However, new research led by Sarah Coyne, a professor of family life at Brigham Young University, found that the amount of time spent on social media is not directly increasing anxiety or depression in teenagers.

“We spent eight years trying to really understand the relationship between time spent on social media and depression for developing teenagers,” Coyne said about her study published in Computers in Human Behavior. “If they increased their social media time, would it make them more depressed? Also, if they decreased their social media time, were they less depressed? The answer is no. We found that time spent on social media was not what was impacting anxiety or depression.”

Mental health is a multi-process syndrome where no one stressor is likely the cause of depression or anxiety. This study shows that it is not merely the amount of time spent on social media that’s leading to an increase in depression or anxiety among adolescents.

“It’s not just the amount of time that is important for most kids. For example, two teenagers could use social media for exactly the same amount of time but may have vastly different outcomes as a result of the way they are using it,” Coyne said.

The goal of this study is to help society as a whole move beyond the screen time debate and instead to examine the context and content surrounding social media use.

Coyne has three suggestions to use social media in healthier ways.

Be an active user instead of a passive user. Instead of just scrolling, actively comment, post and like other content.

Limit social media use at least an hour before falling asleep. Getting enough sleep is one of the most protective factors for mental health.

Be intentional. Look at your motivations for engaging with social media in the first place.

“If you get on specifically to seek out information or to connect with others, that can have a more positive effect than getting on just because you’re bored,” Coyne said.

In an effort to understand teenagers’ mental health and their social media use, researchers worked with 500 youth between the ages of 13 and 20 who completed once-yearly questionnaires over an eight-year span. Social media use was measured by asking participants how much time they spent on social networking sites on a typical day. To measure depression and anxiety, participants responded to questions with different scales to indicate depressive symptoms and anxiety levels. These results were then analyzed on an individual level to see if there was a strong correlation between the two variables.

At age 13, adolescents reported an average social networking use of 31-60 minutes per day. These average levels increased steadily so that by young adulthood, they were reporting upwards of two hours per day. This increase of social networking, though, did not predict future mental health. That is, adolescents’ increases in social networking beyond their typical levels did not predict changes in anxiety or depression one year later.

Co-authors on the study include BYU professors Adam Rogers, Laura Stockdale, Jessica Zurcher and BYU graduate student McCall Booth.

Story Source:

Materials provided by Brigham Young University. Note: Content may be edited for style and length.

Go to Source


Addictive de-vices: How we can unplug from this 21st century epidemic

We spend our days looking at them, talking to them, and touching them.

They increasingly consume our time, attention and money. We are addicted to our digital devices — or, more precisely, the digital experiences they give us.

Now, an article published in the Journal of Public Policy and Marketing, by SFU Beedie professor Leyland Pitt and his co-authors, analyzes the growing problem with digital addiction and how marketers as well as app developers contribute to this 21st-century phenomenon. The researchers also made several public policy recommendations to help with this problem.

According to Pitt, digital addiction is linked to promoting obesity, sleeplessness, increased anxiety, decreased productivity, and relationship issues. It is also a factor in physical dangers related to distracted driving, and walking.

“Digital experiences, like social media, are linked to decreased productivity in the workplace and it’s already costing the U.S. economy $997 billion,” says Pitt. “Today, texting while driving is now six times more dangerous than drinking and driving, and it’s costing the Canadian economy $25 billion.”

He adds, “If you’re checking a text for just five seconds while driving at 90 km/h, you’ve basically travelled the length of a football field blind-folded. That’s incredibly dangerous and foolish when you put it into perspective.”

The researchers say marketers and app developers work together to develop experiences that create an insatiable desire for users to keep returning to their apps. Companies achieve this by using various tactics such as the freemium model, gamification and making their app ubiquitous.

“It seems that digital addiction is impacting young adolescents the most, but that’s because they’ve grown up with digital devices,” says Pitt. “Addiction doesn’t know age. It can happen to anybody.”

Leyland sat down with SFU News recently to share his team’s recommendations for how we can curtail this growing epidemic through changes to public policy.

Product Design

L: I would like to see mandatory labeling for apps. Although this would not entirely prevent addiction to digital experiences, warning labels would likely prompt more conscious decision- making on the part of consumers, and reduce the automaticity often inherent to addiction.

Another strategy would be to mandate natural “stopping points” in digital offerings. This would mean endless games and infinite scrolls would be punctuated with natural breaks, in the same way that books have chapters.

Advertising and Promotion

L: Disclosures could be included in ads for digital products and services, similar to prescription drug ads in the United States or those on food packaging. This could include explicit information on how much time a user spends using an app or service, as well as how much a company is making from a user’s attention and information.

Place and Distribution

L: One prime area for public policy intervention might be in the area of what the World Health Organization calls “distracted walking.” Distracted walking refers to accidents that occur when citizens use their smartphones while walking in public places.

Rather than ban phones in these busy areas, government intervention could shape behavior. For example, in many German cities the street-crossing “walk” and “do not walk” signals are duplicated at ground level so as to be in the line of sight of people looking at their mobile devices.

Price and Cost

L: Digital products could disclose, on average, what in-app purchases typically end up costing and how much time consumers spend using these apps.

In addition, regulators could impose taxes directly on the most addictive offerings, as they have done in the case of tobacco products; alcohol; and, in some cases, prescription drugs.

Fast Facts:

* According to the Canadian Automobile Association (CAA), 80 per cent of collisions and 65 per cent of near crashes have some form of driver inattention as contributing factors.

* According to the CAA, driver distraction is a factor in about 4 million motor vehicle crashes in North America each year.

* According to CAA, the economic and social consequence of road crashes in Canada is estimated to be $25 billion per year, including direct and indirect cost, as well as pain and suffering.

* According to the Canadian Mental Health Association (CMHA), similar neurological responses between compulsive social network sites use and addiction to substances.

* The World Health Organization recognizes gaming addiction as a disease.

* According to National Highway Transportation Safety Administration (NHTSA), texting and driving is six times more dangerous than drinking and driving.

* According to the Overload Research Group, distractions from digital experiences, like social media, in the work place are responsible for the loss of a quarter of each employee and employer’s day. This costs the U.S. economy $997 billion each year.

* In China, mobile phone lanes have been implemented in a number of large cities for pedestrian safety.

Go to Source


“Undress Alert” Helps These Parents Monitor Their Autistic Child

Autism is a spectrum, and many people with the spectrum spend their lives without ever even being diagnosed. That was especially true in the past, which is part of the reason for the apparent rise of autism in recent years. Others, however, have more severe symptoms that can have a significant impact on their lives, and who require more hands-on care. That is the case with Alain Mauer’s son Scott, who often removes his clothes in his bedroom before going over to the bathroom. To help the family monitor Scott and avoid awkward situations, Mauer made a device called UD-Alert.

UD-Alert is a wearable device designed to sound a notification when Scott takes off his shirt or pants. With this device, Scott’s parents will get an alert when he takes off his clothes when he’s alone in his room. UD-Alert was specifically designed to be as small and comfortable to wear as possible — so much so that Scott can wear it while he’s sleeping. It’s also designed to be safe for children with special needs, and particular attention has been put into ensuring that the device and its components can’t be swallowed.

UD-Alert is composed of two separate devices: the transmitter and the receiver. The transmitter is worn on Scott’s pants and the receiver with the alarm is situated in the family’s common area. The two devices communicate over a 433MHz radio signal. The transmitter device, which is built into Scott’s waistband and powered by a CR2032 battery, has a switch that is toggled when a Velcro strip attached to Scott’s shirt is pulled out. A Microchip ATtiny85 microcontroller registers that, and sends a signal to the receiver so that Scott’s parents know that he has taken off either his shirt or pants. UD-Alert was created for a very specific purpose, but it’s an important one for parents who are raising a child with special needs.

Go to Source
Author: Cameron Coward

IEEE Spectrum

FarmWise Raises $14.5 Million to Teach Giant Robots to Grow Our Food

We humans spend most of our time getting hungry or eating, which must be really inconvenient for the people who have to produce food for everyone. For a sustainable and tasty future, we’ll need to make the most of what we’ve got by growing more food with less effort, and that’s where the robots can help us out a little bit.

FarmWise, a California-based startup, is looking to enhance farming efficiency by automating everything from seeding to harvesting, starting with the worst task of all: weeding. And they’ve just raised US $14.5 million to do it.


Turn Your Actual Car Into a Racing Simulator

Hardcore racing simulator enthusiasts can spend hundreds — even thousands — of dollars on their controller setups. The goal is to replicate the feel of a real car as much as possible. Everything from the steering wheel to the brake pedal should mirror the feel of a car. But there is a very good chance you’ve already got a perfectly good car sitting in your driveway. By following Outlandnish’s guide, you can use your actual car as a controller for racing sims.

To do this, you’ll need a car with an OBDII port (as all modern cars do) and either an Xbox One or a gaming PC. While it’s true that the steering wheel and brake pedal likely won’t feel the same when you’re parked and you won’t have the force feedback that some high-end controllers provide, it’s hard to imagine a more realistic racing sim experience than sitting in an actual car. Theoretically, you can even follow Outlandnish’s write-up for a car that doesn’t even run — the author did so with a Subaru BRZ that had a bad engine.

This entire project relies on the CAN (Controller Area Network) bus that is accessible through a car’s OBDII port. The CAN bus is how the car’s various electronics communicate with each other, and it caries information about virtually every aspect of a modern car’s operation. To intercept and utilize messages from the CAN bus, you’ll need a device like the Macchina M2 Under the Dash kit. This particular kit is designed specifically for turning data from the CAN bus into joystick commands.

In order to take advantage of the Macchina M2’s output, you can use an Xbox Adaptive Controller. That controller is built for accessibility, and is incredibly expandable. In this case, you’re using the Macchina M2 as inputs for the Xbox Adaptive Controller via Outlandnish’s breakout board. You will have to use some sort of CAN software to determine which CAN messages correspond to information like throttle position, but there are lots of online guides on how to accomplish that.

From there, it’s just a matter of figuring how where to put an Xbox and TV inside of you car!

Go to Source
Author: Cameron Coward

IEEE Spectrum

Russian Humanoid Robot to Pilot Soyuz Capsule to ISS This Week

Skybot F-850 will spend a week on the ISS charming astronauts with its sense of humor