robertogreco + android + design   14

The Ren'Py Visual Novel Engine
"Ren'Py is a visual novel engine – used by thousands of creators from around the world – that helps you use words, images, and sounds to tell interactive stories that run on computers and mobile devices. These can be both visual novels and life simulation games. The easy to learn script language allows anyone to efficiently write large visual novels, while its Python scripting is enough for complex simulation games.

Ren'Py is open source and free for commercial use.

Ren'Py has been used to create over 1,500 visual novels, games, and other works. You can find them at the official Ren'Py Games List, and the list of Games made with Ren'Py on itch.io."
games  gaming  gamedesign  design  ren'py  visualnovels  if  interactivefiction  lifesimulation  software  mac  osx  linux  chromeos  chrome  android  ios  applications  windows  gamemaking  classideas  writing  multiliteracies  opensource  onlinetoolkit  storytelling 
september 2018 by robertogreco
Redesigning Android Emoji – Google Design – Medium
"Yep, we did it. We said goodbye to the blobs. We moved away from the asymmetric and slightly dimensional shape of the container to an easily scannable squishy circle, relying on bold color, purposeful asymmetry — such as the new mind-blown emoji or the prop-wearing cowboy emoji — and loud facial features to convey emotion.

We also spent a long, long time making sure that we addressed cross-platform emotional consistency. Because one of our main goals with the redesign was to avoid confusion or miscommunication across platforms, we wanted to assure the user that when they sent an emoji to a friend, the message was clearly communicated regardless of whether they are on iOS, Windows, Samsung, or any other platform."
android  emotions  google  design  consistency  communication  2017  color  emoji 
may 2017 by robertogreco
Transit Maps: Apple vs. Google vs. Us — Medium
"Transit maps are beautiful. You see them plastered on bus shelters and subway stops. Your parents kept one in their pockets. You might have one burned into your brain.

A transit map is much more than a list of stations. It’s the underlying anatomy of your city. It shows how people move, how neighbourhoods are connected, and how your craziest city adventures begin.

Of course, transit maps are also incredibly functional: they’re abstract diagrams that show you how your transit system works. They have rigid lines and fixed-angles. While they’re not geographically accurate, they do a pretty good job of helping you figure out how to get from A-to-B. Every transit line has a different colour, and intersecting lines show you where to transfer.

You can ask any transit agency designer: creating a transit map is a painstaking process. Transit agencies put lots of thought into making diagrams that are equally beautiful and functional…

…although no two cities approach transit maps exactly the same way.
Which is great!

Unless you’re trying to design a transit map for every city in the world.

Imagine that: every transit line in every city, condensed into one, single, beautiful, curvy, map. Millions of stops, thousands of lines, hundreds of agencies.

Google Maps and Apple Maps have tried to do it, but we thought we could do better.

They have lots of resources. We don’t. But then again… we have Anton.

In this post, we’ll show you how Anton, our algorithm alchemist, took on both Apple and Google. He’ll be posting a technical follow up soon, so if you’re into that, we’ll let you know on Twitter. (If you want to take our word for it though, maybe just download our app? See our transit maps in all their titillating, unadulterated glory.)"
maps  mapping  application  ios  mobile  android  iphone  googlemaps  applemaps  apple  google  transit  transitapp  publictransit  2016  design 
july 2016 by robertogreco
Android Experiments
"Android was created as an open and flexible platform, giving people more ways to come together to imagine and create. Developers everywhere have used the unique capabilities of the platform to push the limits of what’s possible on phones, tablets, watches and beyond.

We’re working to document creative experiments like these and make them open source so anyone can see how they are made, or get inspired to create their own. Our hope is to encourage more developers to challenge how we interact with the devices we use every day.

Each experiment is submitted by the creator, and all kinds are welcome—no matter your skill level, the framework it uses or the device it runs on. If you’ve created something amazing on Android you’d like to share, please submit your own experiment."

[See also: https://www.youtube.com/watch?v=ws0SQNPgQyw ]
android  applications  code  design 
august 2015 by robertogreco
The End Of Apps As We Know Them - Inside Intercom
"The experience of our primary mobile screen being a bank of app icons that lead to independent destinations is dying. And that changes what we need to design and build.

How we experience content via connected devices – laptops, phones, tablets, wearables – is undergoing a dramatic change. The idea of an app as an independent destination is becoming less important, and the idea of an app as a publishing tool, with related notifications that contain content and actions, is becoming more important. This will change what we design, and change our product strategy.

NO MORE SCREENS FULL OF APP ICONS

This is such a paradigm shift it requires plenty of explaining. Whilst it may not transpire exactly as I’m about to describe, there is no doubt what we have today — screens of apps — is going to dramatically change. Bear with me as I run through the context.

The idea of having a screen full of icons, representing independent apps, that need to be opened to experience them, is making less and less sense. The idea that these apps sit in the background, pushing content into a central experience, is making more and more sense. That central experience may be something that looks like a notification centre today, or something similar to Google Now, or something entirely new.

The primary design pattern here is cards. Critically it’s not cards as a simple interaction design pattern for an apps content, but as containers for content that can come from any app. This distinction may appear subtle at first glance, but it’s far from it. To understand it, and chart the trajectory, we need to quickly run through two things.

1. Designing systems not destinations

I covered this topic in detail in a previous post, so I’ll quickly summarise here. Most of us building software are no longer designing destinations to drive people to. That was the dominant pattern for a version of the Internet that is disappearing fast. In a world of many different screens and devices, content needs to be broken down into atomic units so that it can work agnostic of the screen size or technology platform. For example, Facebook is not a website or an app. It is an eco-system of objects (people, photos, videos, comments, businesses, brands, etc.) that are aggregated in many different ways through people’s newsfeeds, timelines and pages, and delivered to a range of devices, some of which haven’t even been invented yet. So Facebook is not a set of webpages, or screens in an app. It’s a system of objects, and relationships between them.

2. Recent changes to iOS and Android notifications

Things changed with iOS 8 and Android KitKat. Notifications used to be signposts to go to other places. A notification to tell you to open an app. To open a destination.

But that is changing fast. For a while now, you can take action directly in Android notifications. Sometimes that takes you to that action in the app itself, but sometimes you can do the action directly, meaning that you don’t need to open the app at all.



We’ve moved pretty quickly from notifications as signposts, to containers (cards) that include content, and actions on that content."

[Follow-up post: “It's not the end of apps”
http://blog.intercom.io/its-not-the-end-of-apps/ ]
applications  design  ux  mobile  phones  smarthphones  interface  2015  pauladams  content  interaction  ios  android  services  software  notification  cards 
march 2015 by robertogreco
Google Is Designing the Font of the Future -- NYMag
"Among the thousands of features on your smartphone, one you’ve probably never thought about is which fonts it uses. Typography is involved in almost everything we do on our devices — the emails we send and receive, the texts we compose, the tweets we scroll through — yet to most of us, letters are just letters, numbers are just numbers. We might pick Garamond over Comic Sans for a cover letter, but on a phone, who cares?

Google, though, is paying attention. It’s spent years trying to create the perfect fonts for Android devices, a sprawling ecosystem that includes small phones, big tablets, and everything in between. And now, as Google is installing Android into cars, TVs, and watches on your wrist, the company is attempting an audacious task: making a typeface that looks good on all of them.

“Typography is kind of the skeleton. It’s the unsung hero,” Matias Duarte, Google’s vice president of design, said in an interview this week. "We’re trying to give people one logical, consistent system.”

Google’s efforts to perfect a universal typeface began in 2005, when it acquired a small operating-system-maker named Android. Two years later, it released Droid, a family of fonts designed by type-design firm Ascender specifically for use on Android devices. Until Droid, many fonts used in mobile applications were holdovers from the desktop age — Helvetica, Arial, Verdana, and other household names. Droid looked markedly better on smartphones than those typefaces, but it had problems of its own. Droid fonts worked best on small, low-resolution screens like the ones on early Android phones. But on the larger, high-definition screens that were introduced in later models, the fonts looked off. The bold letters were too blocky, and some of the non-bold letter forms, which had been designed for low-pixel-density screens, looked insubstantial and oddly spaced in high resolution. "Droid struggled to achieve both the openness and information density we wanted," Duarte later wrote in a Google+ post."



"Roboto wasn’t an immediate hit. Some type geeks dismissed it as a “Frankenfont,” a pastiche that borrowed heavily from other popular fonts, including Helvetica, the famous font that inspired a 2007 documentary. “Roboto is a Helvetica rip-off. It’s Google’s Arial,” tech blogger Jon Gruber wrote. Typographer Stephen Coles labeled it “an unwieldy mishmash,” and said, “This is not a typeface. It’s a tossed salad.” And though others were more complimentary – Glenn Fleishman wrote that "Roboto pricks at your sense of the familiar at first, but then, like a person you see passing in a crowd that you believe is a friend, and then on fully facing realize is a stranger, the font asserts its own identity" — Roboto was never truly embraced by the small community of designers who pay close attention to things like exit angles and ball terminals. (Google isn't alone in this; Apple's choice to use an existing typeface for iOS, rather than create its own custom typeface, has also come under heavy scrutiny from designers.)

Unlike pre-digital fonts, which were essentially set in stone after being finished, Google got to keep working on Roboto. And in subsequent editions, the typeface got a face-lift. The uppercase B got a little slimmer. The comma was made less angular. “The old model for releasing metal typefaces doesn’t make sense for an operating system that is constantly improving,” Duarte said. “As the system evolves over time, the type should evolve along with it.”

With its latest operating system, Android L, Google has made the most dramatic update to Roboto yet. The changes are part of Google's new, somewhat inscrutable "material design" initiative, and unless you study fonts, you might not notice the difference. But under the hood, there’s a lot going on."



"Unlike most innovations in computing, typeface design doesn't succeed by grabbing your eye. In fact, if you notice the changes in the new version of Roboto, Robertson and his team have probably done something wrong. The goal of a good font is to be silently useful, to improve a readers's experience without calling too much attention to itself. But if you notice, in the coming months, that your Moto X or your Samsung smartwatch suddenly starts to feel a little sleeker, and your emails and tweets get a tiny bit easier to read, it might be the new Roboto at work behind the scenes."
google  android  typography  design  kevinroose  2014  fonts  droid  roboto  googlefonts 
july 2014 by robertogreco
Material world: how Google discovered what software is made of | The Verge
"We’re hardwired to comprehend physical things, Duarte says, and software all too often behaves in ways that break with our models and expectations. Wiley thinks of it as breaking the suspension of disbelief, as when something happens in a sci-fi movie that doesn’t follow its own internal logic. Duarte is a little more direct, with a subtle dig at Apple’s iOS and its flying software layers: "We’re not hurtling you through space at high speeds," he says. "We’re not puncturing your hand with invisible, impossible surfaces."

"Design is all about finding solutions within constraints," Duarte says, "If there were no constraints, it’s not design — it’s art."

Google’s designers steadfastly refuse to name the new fictional material, a decision that simultaneously gives them more flexibility and adds a level of metaphysical mysticism to the substance. That’s also important because while this material follows some physical rules, it doesn’t fall into the old trap of skeuomorphism. The material isn’t a one-to-one imitation of physical paper, but instead it’s "magical," as Duarte puts it.

It can do things that physical paper can’t, like grow and shrink with animations. Those animations were important to Google, because they help users understand where they are inside an app. "A lot of software … kind of feels like television or film in terms of jump cuts," Wiley says, causing you to lose your sense of time and place. For apps, you want something more akin to a stage play. "It’s going from one moment to the next," he says, "that scene change, and what’s happening onstage is choreographed and transitioned, and there’s meaning.""
design  android  google  materialdesign  constraints  rules  2014  dieterbohn  xeroxparc  objects  predictability  matiasduarte 
june 2014 by robertogreco
We Didn’t Even Bother with a Funeral | dirtystylus
The guys who were quiet? They were the ones who realized that Flash was still good for a great many things, but for mobile it was going to be native apps or open web technologies. So they put their heads down and went to work, picking up new skills or brushing up old ones. Meanwhile, some of their colleagues shook their fists at Apple and played the waiting game, promising that each new release on Android would finally bring the “full web experience”. It was late to arrive, and never delivered on the promise. So now comes the inevitable news, and everyone shrugs. The ones who got a head start are busy learning and growing elsewhere; the blowhards have probably just found another symbolic divide to rally their banners around.
internet  apple  working  flash  markllobrera  2012  mobile  design  adobe  android  iphone  ios  ipod  learning  change  adaptability  via:tealtan 
august 2012 by robertogreco
Augmented Paper - Matt Gemmell
"For me, software experiences that feel like Augmented Paper are those that second-guess our (developers’) natural tendency to put functionality first, or to think of our apps as software. Apps are only incidentally software; software is an implementation detail. Instead, apps are experiences. Design an experience. Make it as beautiful — and as emotionally resonant — as it can possibly be. Then adorn the core experience and content with only as much functionality as is absolutely necessary. Functionality…is like seasoning. A little is an enhancement; any more destroys the flavour…and may well be bad for you. These new classes of devices, so immediately personal and portable and tactile, aren’t desktop-era shrines demanding incantation and prostration. They’re empowering extensions to our real, actual lives - and that’s a profound thing. They take what was once prosaic or mundane, and give us just a taste of superpowers. They’re augmentations, and they should be beautiful."
instapaper  aesthetics  tactile  clear  invisibleinterfaces  instinctivecode  digital  minimalism  skeuomorph  tablets  augmentation  mobile  ipad  iphone  applications  augmentedpaper  mattgemmell  2012  via:preoccupations  designasexperience  ui  ux  windowsphonemetro  windowsphone7  metro  windows  design  ios  apple  android  wp7  from delicious
april 2012 by robertogreco
Every user a developer, part II, or: Momcomp « Adam Greenfield's Speedbird
"The things which I’ve painted as trivial here are admittedly anything but. But they are, I sincerely believe, how we’re going to handle — have to handle — the human interface to this so-called Internet of Things we keep talking about. Each of the networked resources in the world, whether location or service or object or human being, is going to have to be characterized in a consistent, natural, interoperable way, and we’re going to have to offer folks equally high-level environments for process composition using these resources. We’re going to have to devise architectures and frameworks that let ordinary people everywhere interact with all the networked power that is everywhere around them, and do so in a way that doesn’t add to their existing burden of hassle and care.

Momcomp, in other words. It’s an idea whose time I believe has come."
programming  future  internetofthings  development  design  adaptive  ux  ui  tools  momcomp  usability  android  everyware  adamgreenfield  participation  google  appinventor  interaction  invention  literacy  computing  content  mobile  making  technology  alankay  hypercard  jefraskin  bencerveny  junrekimoto  tednelson  dougengelbart  spimes  iot 
july 2010 by robertogreco
Every user a developer: A brief history, with hopeful branches « Adam Greenfield's Speedbird
"the corpus of people able to develop functionality, to “program” for a given system, has been dwindling as a percentage of interactive technology’s total userbase…Alan Kay’s definition of full technical literacy, remember, was the ability to both read & write in a given medium — to create, as well as consume. And by these lights, we’ve been moving further & further away from literacy & the empowerment it so reliably entrains for a very long time now. … we need to articulate a way of thinking about interactive functionality & its development that is appropriate to an era in which virtually everyone on the planet spends some portion of their day using networked devices; to a context in which such devices & interfaces are utterly pervasive in the world, & the average person is confronted with a multiplicity of same in the course of a day; and to the cloud architecture that undergirds that context. Given these constraints, neither applications nor “apps” are quite going to cut it"
android  everyware  adamgreenfield  participation  google  appinventor  interaction  invention  literacy  computing  content  design  development  programming  mobile  making  technology  alankay  hypercard  jefraskin  bencerveny  junrekimoto  tednelson  dougengelbart 
july 2010 by robertogreco
Square
"In February 2009, Jim McKelvey wasn’t able to sell a piece of his glass art because he couldn’t accept a credit card as payment. Even though a majority of payments has moved to plastic cards, accepting payments from cards is still difficult, requiring long applications, expensive hardware, and an overly complex experience. Square was born a few days later right next to the old San Francisco US Mint.

Today the Square team is focused on bringing immediacy, transparency, and approachability to the world of payments: an inherently social interaction each of us participates in daily. We’re starting with a limited beta and rolling out to everyone in early 2010."
android  iphone  ipad  payment  processing  creditcards  credit  ecommerce  commerce  glvo  applications  business  mobile  money  design  services  retail  twitter  technology  tools  ios 
may 2010 by robertogreco
Daring Fireball Linked List: 'The Gadget Disappears'
"Love this line from the New York Times’s David Carr on the Charlie Rose show, regarding the iPad:
One thing you have to understand about this gadget is that the gadget disappears pretty quickly. You’re looking into pure software.

I don’t think it’s a coincidence that Carr is a business reporter, not a tech reporter. He sees the forest, not the trees. But this is really astute. I’ve been using a Nexus One Android phone for the last few weeks, and Carr’s quote summarizes the fundamental difference between Android and iPhone OS. On the iPhone, once you’re in an app, everything happens on-screen, with touch. Everything. You go outside the screen to the home button to leave the app or the sleep button to turn off the device. On Android, many things happens on screen with touch, but many other things don’t, and you’re often leaving the screen for the hardware Back, Menu, and Home buttons, and text selection and editing requires the use of the fiddly trackball. An Android gadget never disappears."
daringfireball  johngruber  ipad  invisibletechnology  iphone  interface  ui  touchscreen  buttons  apple  android  davidcarr  design 
february 2010 by robertogreco
lorbus » Blog Archive » 10 Ways To Make An iPhone Killer
"device is screen. Preload with basic software. Allow complete software personalization. Free idea, mods & software exchange. Phones fall, design accordingly. Involve more senses. Camera companies are dead. Charge through induction. More status levels."
iphone  mobile  phones  design  android  google  computing  haptics  induction  senses  customization  open  freedom  personalization 
june 2008 by robertogreco

related tags

adamgreenfield  adaptability  adaptive  adobe  aesthetics  alankay  android  appinventor  apple  applemaps  application  applications  augmentation  augmentedpaper  bencerveny  business  buttons  cards  change  chrome  chromeos  classideas  clear  code  color  commerce  communication  computing  consistency  constraints  content  credit  creditcards  customization  daringfireball  davidcarr  design  designasexperience  development  dieterbohn  digital  dougengelbart  droid  ecommerce  emoji  emotions  everyware  flash  fonts  freedom  future  gamedesign  gamemaking  games  gaming  glvo  google  googlefonts  googlemaps  haptics  hypercard  if  induction  instapaper  instinctivecode  interaction  interactivefiction  interface  internet  internetofthings  invention  invisibleinterfaces  invisibletechnology  ios  iot  ipad  iphone  ipod  jefraskin  johngruber  junrekimoto  kevinroose  learning  lifesimulation  linux  literacy  mac  making  mapping  maps  markllobrera  materialdesign  matiasduarte  mattgemmell  metro  minimalism  mobile  momcomp  money  multiliteracies  notification  objects  onlinetoolkit  open  opensource  osx  participation  pauladams  payment  personalization  phones  predictability  processing  programming  publictransit  ren'py  retail  roboto  rules  senses  services  skeuomorph  smarthphones  software  spimes  storytelling  tablets  tactile  technology  tednelson  tools  touchscreen  transit  transitapp  twitter  typography  ui  usability  ux  via:preoccupations  via:tealtan  visualnovels  windows  windowsphone7  windowsphonemetro  working  wp7  writing  xeroxparc 

Copy this bookmark:



description:


tags: