Feature Discussion - noyainrain/meetling GitHub Wiki

The boot pages may benefit from a support contact (link or email address). Contact info could be passed as parameter to the micro boot template.

With data-binding, editing in-place is easier to implement, so maybe we should give it another try with the next page or component.

<!--
micro-editable shows the first child by default and the second if in edit mode.
When the parent edit is set to true, editables are toggled and some other
elements are disabled etc.
-->
<micro-editable data-edit="edit">
    <p data-content="format foo"></p>
    <input data-value="foo"></input>
</micro-editable>
<button is="micro-button" class="action" data-disabled="edit">Go!</button>

See also: http://bazaar.launchpad.net/~noya/spreact/trunk/view/head:/spreact/ui/res/static/js/spreact/ui/ui.js

Logging errors is not enough and just a fallback. Errors should be reported via notification channel(s) specified via command line / config. Authentication details needed for some channels can be gathered manually and given via command line / config.

There are two types of errors, infrastructure/environment (i.e. Redis connection problems) and bugs, which should be presented differently ("you should have a look" vs "please report a bug").

Implement simple (db-agnostic) message.py library, which can be used for both error reporting and user notifications:

# token, auth_request and auth are simple strings

# authentication not mandatory
token = '[email protected]'
channel = EmailChannel(token)
channel.send(...)

auth_request = TelegramChannel.authenticate()
# ... get auth via third party...
token = TelegramChannel.finish_authenticate(auth_request, auth)
channel = TelegramChannel(token)
channel.send(...)

The same API can be used for chat rooms, minus the ability to use the authentication flow to log in.]

A prototype implementation is available in the experimental message branch.

Search keywords:

• online / open source web collaborative / shared list
• list share by link / url

https://softwarerecs.stackexchange.com/questions/32290/online-collaborative-list-without-registration

https://trello.com/ (or open source alternatives) is a kind of general purpose list of lists

It would be nice to have a common focus style, instead of using the browser default. Ideally hover and focus should look alike. Here are some ideas:

:focus {
    outline: none;
    border: 1px solid #4d8dd9;
    box-shadow: inset 0 0 0 1px #4d8dd9;
    text-decoration: underline;
}

The secret share link of a meeting technically ensures that only allowed participants have access to it. An optional password could nevertheless increase protection in case the share link is leaked (for example by accidentally posting it to a public website or a social media feed or by simply sending it to the wrong people).

Have a look at mailin for a self-hosted solution for incoming mail for Helpy. To make it work alongside with Postfix, we could for example forward only a specific address with transport.

To update micro objects/properties, we could iterate over all keys, like:

if version < 42:
    for key in r.keys('*'):
        try:
            object = r.oget(key)
        except ResponseError:
            pass
        else:
            if object['__type__'] == 'User':
                object['email'] = None
            if object['__type__'] == 'Object':
                del object['trashed']
            # ...
            r.oset(object['id'], object)

However, for objects inheriting from micro classes (e.g. Meeting from Editable), we would have to know the class hierarchy. This could be achieved by storing the hierarchy with the object (e.g. __types__ = [...]) or by a mapping that must be provided (e.g. {Meeting: [Editable]}) or by importing the class and inspecting the hierarchy.

Because every micro app needs some boilerplate HTML (like the JavaScript / compatibility check), a micro base template might be sensible. Some refactoring has been started in the experimental branch https://github.com/NoyaInRain/meetling/tree/micro-template .

A prototype implementation is available in the experimental branch https://github.com/NoyaInRain/meetling/tree/telegram .

• Best UX:
  1. Control that allows valid input only (e.g. calendar)
  2. Control that allows arbitrary text input, but gives feedback about invalid values (the faster, the better)
• For i. wee need client side validation
• Pros:
  • Better UX
  • Get rid of InputError (use standard ValueError and TypeError)
  • More consistency: Validate type and value on the client, not only type (as done now by converting input to JSON)
• Cons:
  • Not DRY, server and client validation will be redundant
• Experiment with client side validation and see how much redundant logic is introduced (for the most part validation shouldn't be that complex, often check for emptiness/null or ranges)

micro could consist of three components with a functionality like:

micro-server:

• micro
  • Application
  • Object
  • Editable
  • User
  • Settings
  • ...
• server
  • Server
  • Endpoint

micro-client:

• micro
  • UI
  • Page
  • SimpleNotification
  • Menu
  • TimeInput
  • UserElement
  • UserListingElement
  • ...

micro-boilerplate: See boilerplate in current micro repository

A convention for styling content of different priority levels could roughly look like:

• Most of the UI follows this pattern, but some parts deviate (e.g. form labels (are additionally reduced in size); heading for actions)
• How about creating CSS classes for the different levels?

We could wrap pythonapi.rst/webapi.rst in .. default-role:: py:obj/.. default-role:: ref and .. default-role::.

Deleting an object permanently can be challenging, because references to it may be used throughout the app. Special care must be taken if removing the references is not preferable (e.g. for users):

• User:
  • Referenced in Meetling.users, Editable.authors (= Settings, Meeting, AgendaItem)
  • Action: Anonymize, i.e set all fields to None and the name to e.g. Former user
• Meeting:
  • Referenced in: Meetling.meetings
  • Remove from meetings along with all agenda items
• AgendaItem:
  • Referenced in: Meeting.trashed_items
  • Remove from trashed items

Trashed objects could be registered with a due time. When the due time is reached, a garbage collection could be triggered that performs the necessary actions for deletion.

We could enhance printing by (sorted from lowest to highest effort):

• Tweaking the website to be better suited for printing - for example using the complete width of a page:

@media print {
    .meetling-page-inside {
        max-width: none;
    }
}

• Adding a print button to the presentation mode (once it is implemented)
• Adding a dedicated print view

A more flexible input format for duration values would be nice. Possible options: 2:30 (looks like a time), 2h30m (not easily localizable), 2 hours, 30min (non-trivial to parse), two fields for hours and minutes (use case for hours is rare).

A) Inherit from input (type=text/check):

• (-) No custom content
• Effort:
  • Implement only a few attributes/properties (value, readonly, ...)
  • Disable superfluous attributes

B) Wrap input:

• (-) Form compatibility only via hidden input hack
• Effort:
  • Implement all attributes/properties (often transfer value to hidden input)

Details:

• Attributes/properties: name, value, readonly, required, defaultValue, ...
• Superfluous attributes/properties: type, pattern, ...
• Depending on the type, some more attributes/properties are needed/superfluous: placeholder, min/max, ...

Before printing text (in text emails, log output, ...), collapse white space, handle newline characters (depending on whether line breaks are allowed) and wrap it nicely. Maybe the textwrap module could be useful.

If there is one day the need for subpages, we could convert the action bar into a menu bar that mixes links and actions.

1. Log in automatically (implemented)
2. Perform any action (e.g. like, edit, ...) instantly
3. After the first action, ask the user once for their name (let others know who you are) and email address (for notifications)

class Meetling:
    def prepare_login(self, email=None):
        """Create an one-time login code for either the current *user* or the user given by *email*.

        If no user with *email* exists, a :exc:`ValueError` (``email_not_registered``) is raised.
        The code should be transmitted to the user in a safe way. The code can then be used by
        :meth:`login` to log in.
        """
        user = self.user or self.users[self.r.hget('emails', email)]
        login_code = randstr()
        self.r.set(login_code, user.auth_secret)
        self.r.expire(login_code, 24 * 60 * 60)
        return login_code

    def login():
        """
        A login code can only be obtained via the UI.
        """
        if code:
            id = self.r.get(code)
            if not id:
                raise ValueError('code_invalid')
            self.r.delete(code)

Make it possible to create a follow-up meeting, for which some properties of the current meeting (e.g. description, list of subscribers, ...) are copied, new default values for some properties (e.g. time + one week) are proposed and the option to transfer some agenda items (think of items that have been delayed or that need the attention of a second meeting) is given.

By default the line will wrap between words if the title consists of multiple words.

.meetling-start-logo span {
    white-space: nowrap;
}

Needed e.g. for Settings.provider_description.

{
    'a': [int], # list of integers
    'b': {str}, # dict of strings
    'c': {'d': str, 'e': {'f': int}}
}