# oui
Making highly reusable UI components for sound recognition pipelines.
If more people use a component, reuse is a given.
So how do we make more people use a component?
The component should be:
* useful
* easy to use
* easy to adapt (because one size rarely fits all)
We should have three "contexts" in mind:
* use in front-end dev
* use from python (dash -- or other py-js bridgin tool)
* use from python (jupyter notebooks)
What components?
Some really high level ones (lists, tables, nested data)?
Some more specific: Hear/view sound, configs CRUD, etc.
# Architectural notes
The following are just suggestions, but follow them unless you have a
defendable reason not to. Also, do add/edit these if you have some ideas of your
own.
One folder per component, with python interface in the `__init__.py` under it.
If python and js need to share some resources (say settings, defaults, etc.),
put these in ONE place (for example a json file) from which both python and js
will source these.
Include as many defaults and annotations as possible. We want the components to
be used out-of-the-box, and only tuned if and when needed.
Defaults can be dumb values, or "smart"
(set dynamically according to the context)
Name your values. For example, instead of `24` or `3600` in the code, define
`HOURS_PER_DAY = 24` and `SECONDS_PER_HOUR = 3600` and use these names.
Extract as many variables from the code and and perculate them higher in the
interface (such as function arguments or module constants).
# Components
Keep in mind: What are our abstract objects and operations that we want the user
to perform on these, and what ways can we provide to do so.
What kinds of ways can I allow the user to view, navigate, search, create,
or edit... lists, tables, nested data?
What kinds of data do we typically deal with, and in what form, and what
do we do with this data? We have sounds and annotations thereof.
We want to be able to upload and download sounds, hear and view them, do
CRUD on annotations, go from annotations to annoted (sound) and see
what annotations we have for a given sounds.
Etc.
## Lists
Ways to view lists of jsons.
Needs a list nevigation and a json viewing protocol.
## Tables
Ideally one that tries to adapt automatically to a context
(e.g. what do we do when the table is too small/big horizontally/vertically),
but with many properties than can be turned off/on or parametrized
(e.g. sortable, searchable, collapsable, etc)
## Nested data
Collapse/Expand file tree view?
Page by page flat view?
## Configs CRUD
## Hear sound
What do we do when the sound is big?
## View sound
What do we do when the sound is big?
### Spectrogram
What do we do when the sound is big?
### waveform plot (and aggregates)
## Putting viewing and hearing together
## Splatter stuff
## Named selections
Of sounds, annotations, etc.
# Contents
## useful
## easy
## adaptable
# Reusability tricks
## useful
## easy
## adaptable
Raw data
{
"_id": null,
"home_page": "https://github.com/otosense/oui",
"name": "oui",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "User Interface,UI,sound recognition",
"author": "",
"author_email": "",
"download_url": "https://files.pythonhosted.org/packages/c2/b6/aa5b724780edbdd4e0d05ed7d0b21efd7e8c40ec03916dace29b1c296b93/oui-0.3.3.tar.gz",
"platform": "any",
"description": "# oui\n\nMaking highly reusable UI components for sound recognition pipelines. \n\nIf more people use a component, reuse is a given. \nSo how do we make more people use a component?\nThe component should be:\n* useful\n* easy to use\n* easy to adapt (because one size rarely fits all)\n\nWe should have three \"contexts\" in mind:\n* use in front-end dev\n* use from python (dash -- or other py-js bridgin tool)\n* use from python (jupyter notebooks)\n\nWhat components?\nSome really high level ones (lists, tables, nested data)?\nSome more specific: Hear/view sound, configs CRUD, etc.\n\n# Architectural notes\n\nThe following are just suggestions, but follow them unless you have a \ndefendable reason not to. Also, do add/edit these if you have some ideas of your\nown.\n\nOne folder per component, with python interface in the `__init__.py` under it. \n\nIf python and js need to share some resources (say settings, defaults, etc.), \nput these in ONE place (for example a json file) from which both python and js \nwill source these.\n\nInclude as many defaults and annotations as possible. We want the components to \nbe used out-of-the-box, and only tuned if and when needed. \nDefaults can be dumb values, or \"smart\" \n(set dynamically according to the context)\n\nName your values. For example, instead of `24` or `3600` in the code, define\n`HOURS_PER_DAY = 24` and `SECONDS_PER_HOUR = 3600` and use these names. \n\nExtract as many variables from the code and and perculate them higher in the \ninterface (such as function arguments or module constants). \n\n\n# Components\n\nKeep in mind: What are our abstract objects and operations that we want the user \nto perform on these, and what ways can we provide to do so.\n\nWhat kinds of ways can I allow the user to view, navigate, search, create, \nor edit... lists, tables, nested data?\n\nWhat kinds of data do we typically deal with, and in what form, and what \ndo we do with this data? We have sounds and annotations thereof. \nWe want to be able to upload and download sounds, hear and view them, do \nCRUD on annotations, go from annotations to annoted (sound) and see \nwhat annotations we have for a given sounds.\n\nEtc.\n\n\n## Lists\n\nWays to view lists of jsons. \nNeeds a list nevigation and a json viewing protocol.\n\n## Tables\n\nIdeally one that tries to adapt automatically to a context \n(e.g. what do we do when the table is too small/big horizontally/vertically), \nbut with many properties than can be turned off/on or parametrized \n(e.g. sortable, searchable, collapsable, etc)\n\n\n## Nested data\n\nCollapse/Expand file tree view?\nPage by page flat view?\n\n## Configs CRUD\n\n## Hear sound\n\nWhat do we do when the sound is big?\n\n## View sound\n\nWhat do we do when the sound is big?\n\n### Spectrogram\n\nWhat do we do when the sound is big?\n\n### waveform plot (and aggregates)\n\n## Putting viewing and hearing together\n\n## Splatter stuff\n\n## Named selections\n\nOf sounds, annotations, etc.\n\n# Contents\n\n## useful\n\n## easy\n\n## adaptable\n\n\n# Reusability tricks\n\n## useful\n\n## easy\n\n## adaptable\n",
"bugtrack_url": null,
"license": "mit",
"summary": "There is a bit of an air of mystery around this project...",
"version": "0.3.3",
"split_keywords": [
"user interface",
"ui",
"sound recognition"
],
"urls": [
{
"comment_text": "",
"digests": {
"md5": "555df2dd680ef1b94e6e4aaf31fee089",
"sha256": "d32ab4bf0eaac2d413d5b475fe7ffae861e98b3076486d3763705944c920f81d"
},
"downloads": -1,
"filename": "oui-0.3.3-py3-none-any.whl",
"has_sig": false,
"md5_digest": "555df2dd680ef1b94e6e4aaf31fee089",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 285647,
"upload_time": "2022-12-31T14:48:41",
"upload_time_iso_8601": "2022-12-31T14:48:41.278300Z",
"url": "https://files.pythonhosted.org/packages/54/9d/0f6be76a97c36ff7506718909d61e9359f19cd394c6d746a0b3ee481f00e/oui-0.3.3-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"md5": "9546aca20004490c8b4e46894f44992f",
"sha256": "3f18bac96dd1333f85d27506395e8604a060d4c0261632bfbd3fd07929ca1c84"
},
"downloads": -1,
"filename": "oui-0.3.3.tar.gz",
"has_sig": false,
"md5_digest": "9546aca20004490c8b4e46894f44992f",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 281606,
"upload_time": "2022-12-31T14:48:42",
"upload_time_iso_8601": "2022-12-31T14:48:42.714426Z",
"url": "https://files.pythonhosted.org/packages/c2/b6/aa5b724780edbdd4e0d05ed7d0b21efd7e8c40ec03916dace29b1c296b93/oui-0.3.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2022-12-31 14:48:42",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "otosense",
"github_project": "oui",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "oui"
}