Skip to content

Feature Discussion

Jump to bottom Edit New page
Sven edited this page Mar 7, 2017 · 36 revisions

Collaborative lists

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

Name Scope Share by URL Registration free Tasks Voting Open Source Note
Listly General x x Mostly for collections
Chacy Poll x x x
Flask Lists Tasks x x x
Wunderlist Tasks x
Workflowy Editor x x
Checkvist Editor x x

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

micro Button form validation

// Take special care for submit buttons in forms: If all is good, prevent default
// submitting and trigger. If the form is invalid, do not trigger and let the default
// validation handling kick in.
if (this.form && this.type === 'submit') {
    if (this.form.checkValidity()) {
        event.preventDefault();
        this.trigger();
    }
} else {
    this.trigger();
}

Focus style

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;
}

Password protected meetings

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).

Incoming mails for Helpy

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.

micro update

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.

micro base template

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 .

Notifications via Telegram

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

Client input validation

  • 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 API

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

Prominence levels

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

Level color font-size Miscellaneous
primary #333 1rem
secondary #888 1rem
detail #888 0.875rem right-aligned
  • 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?

default-role for more compact documentation

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

Deleting objects permanently

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.

Enhance printing

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

Flexible duration format

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).

How to implement custom input elements?

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, ...

Text / white-space handling

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.

Menu for subpages

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

New user flow

  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)

Enhance login with one-time tokens

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)

Follow-Up meetings

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.

Prefer line wrapping between icon and title for start page logo

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

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

Recursive / container check for Endpoint.check_args()

Needed e.g. for Settings.provider_description.

{
    'a': [int], # list of integers
    'b': {str}, # dict of strings
    'c': {'d': str, 'e': {'f': int}}
}
Add a custom footer
Add a custom sidebar
Clone this wiki locally