Comments (5)
I'm going to close this. I see no reason to include UI-specific bits in a machine-readable thing description.
What makes more sense is to include a top-level metadata section which could include things like:
- Manufacturer
- Model
- Software version
With that information, any UI could pick specific icons as necessary.
from api.
We fulfilled a part of this idea in 0.5 by letting users select an image icon for custom things.
The enhancement idea would be complete (in terms of satisfying my original request) if a web thing description could include a pointer to its own custom icon. Icons might be downloaded locally to the gateway as part of installing an add-on, or they could be downloaded from the Internet when a thing is added to the gateway.
Emoji's have become a standard. Similarly, maybe "thing" icons could become part of the proposed standard web of things schema definitions. This enhancement idea would enable product vendors to create their own variant, just as there are multiple artistic renditions of emoji's.
from api.
There is currently no way to define branding information or images in a Web Thing Description. This would need to be a new feature of the spec, like icons in web app manifests https://w3c.github.io/manifest/#icons-member
I'm not sure I like the UI design you propose, but we may need to provide a mechanism for web things to define their own icons and somehow fit that into the UI design (it wouldn't work very well with our current design).
from api.
Alternative ui approach is to have the wot spec define specific icons for each thing type (for example, the icons we already have for a light bulb, power plug, and switch), and then allow customized backgrounds around those icons. (Not sure technically how to accomplish this -- maybe images are optionally fetched from a link associated with the description of the thing.) Brands could try to embed a tiny logo in the background image, or use some brand-specific colors. But even with custom backgrounds, the on/off value or other changed state of a device would still need to be obvious to the end-user.
I think of how emoji's are curated by a standards body. Thing type icons could be curated as part of the wot spec, but other graphics data visually tied to those standard icons could be a way to identify the associated brand.
Because the wot spec isn't ready for this yet, this issue can be a future "story" concept, not high priority.
from api.
I don't think it's really appropriate or scalable for the WoT spec to specify icons for every thing type. There are likely to be thousands of domain specific web thing types in future, defined by external schemas. We're probably eventually going to want to move the current thing type definitions out of the spec into an external schema as well.
What we could do in future is allow extension add-ons to provide front end web components for collections of thing types that correspond to certain schema repositories e.g. a collection of icons for medial IoT devices, or industrial IoT devices etc. We can also allow users to set their own custom icons for individual Things, like SmartThings does.
A better approach for native web things might be for the thing itself to define its own icon in a Thing Description, which could then be branded.
from api.
Related Issues (20)
- type vs. mediaType vs. contentType
- Localisation (l10n) HOT 6
- CODE_OF_CONDUCT.md file missing
- [Question] Things Firmware Update HOT 2
- Default on change event for some properties
- Add WebSocket Gateway events
- Define which members are mandatory vs. optional HOT 6
- base member
- Include human-readable label in Property resource HOT 4
- Support "format" member for a property
- Consider removing object wrapper from Property payload HOT 12
- Add "auto" to HeatingCoolingProperty HOT 1
- What is the project's relationship with W3C WoT? HOT 1
- Join "Project Connected Home over IP"? HOT 1
- Allow properties to indicate if they may be logged HOT 1
- Why is Mozilla Web Thing API different from W3C Web of Things? HOT 3
- More descriptive license HOT 3
- @type should be at top level of action HOT 2
- Support for multiple @context (aka support for Linked Data) HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api.