[new] [Language]


MetaText.GA .. todo ..

Redesign Frontend Newsreleaser

Inspired by


  • Attract, Reward, Enslave, Score
  • In other words: Monetize!


  • UI: Clean, Clear, Cinch, Cool, Consistent
  • UX: Electric, Easy, Expressive, Expected
  • DV: Improvable, Extensible


Look trough the eyes of the people that are interacting (actual or prospective) with the NR-webapp

I would say:

  • Concentrate on potential monitizees [1]
  • Rookies first (satisfy new visitor)
  • Profi's second (keep returning visitors and news-junkies engaged)

Note! This section is poor and needs work.

[1] Monitizees :people who make the money flow to NR. 
Identify, focus, prioritize, budget (time/money/creativity). 
All attention should be on the big spenders. 
Be it on ads, services or whatever. 
BTW: We should not forget the contributors (people 
participating in the project).

UI Improvements

Reduce Server-Cycles where and when possible

  • Improve querying of news articles

Improve mapping of function/aspect to UI-element

Unbalanced main menu

  • The main menu is populated with the names of the main functions (navigation between the main functions of the app) and the names of the supported languages (union of the UI-languages (en,nl) and News-languages (ar,en,fr,nl,tr). This approach is confusing.
  • The main-menu should deal with high level navigation. 'The names of these languages don't belong there. Language-selection must go.
  • !!! Where and how to implement UI-language selection?
  • The main-menu should have more than one level (dropdown, whatever) to make it easily extensible
  • The main-menu (and all other UI-components) should follow best practice and convention

All news (Latest and Search) on one and the same page

Simple API, simple UI

  • A new UI-component (whatnews) has to fully support the API of the backend.
  • Requirement. A new language-global has to be introduced: news_language. Currently the news_language is derived from active_language (the UI-language). In fact the two types are conceptually and technically completely different and have to be managed differently. This is trivial in theory but tricky in practice. Code has to be extended and/or revised in many places in controllers and templates.
  • Setting the UI-language requires a new UI-component (currently in the main menu)


The conceptual (and factual) API boils down to:

  • Example
  • /en/2018-08-31T06:21:58/2018-08-31T07:21:58/none
  • English / FromDateTime / TillDateTime / search-phrase (none => don't do a full text search)
  • See also API and current UI below

Current status of the UI

In the current webapp the UI doesn't support the versatility of this simple API. In the home page you'll get the 'latest news': all news items that have been collected in the previous hour. The preferred news-language is derived from active_language (in fact the language most recently selected from the main menu by the user).

If you want to (full text) search the news you have to go to a dedicated search page to fill in a form with two fields: phrase and hours. Newsrelaser will respond with the articles in the active language, collected within the date-time range and containing the search phrase. The 'untill date-time' is always 'now'. The 'from date-time' is 'now' minus the supplied number of hours.

In the current release of the app it is impossible to specify a different `untill date-time`. It is always `now`. That's annoying. For example. It is impossible to retrieve the articles about Brexit that appeared in august 2017. A redesigned UI has to provide an intuitive and easy way to unlock the full potential of the API. In this new WhatNews-UI-component the user can easily change the defaults for DT-From, DT-Till and SearchFor. News-Language must also be part of this UI-component. Moving the language-choice from the main menu to WhatNews leads to a simpler, less confusing `main menu` that only provides what it should: navigation between the main functions of the app.

One App - One Face

  • Main Problem: myNewsreleaser, configuration, heavy forms (small screens)


  • Mobile first (news retieval / presentation)
  • Same looks/interaction on all screen sizes


Persisting Problems Require Sophisticated Solutions

Unacceptable Slow Search Queries

  • Problem. In most cases FTS-queries takes to long causing a disappointing user experience, putting them of, and consequently eroding the user base. hurting .
  • Tentative Solutions
    • Server-side caching of querie results. Server caching of FTS queries has some drawbacks. It only works when a lot of users request a FTS-querie with the same phrase. Re-users are missing out the from the latest results. The longer the cache-interval, the more outdated are the results.
    • Use a faster DB. Migrating from MongoDB to MySQL might solve this problem. Such a migration requires a substantial effort that is only warranted if the turn around time is reduced by a factor 10 or more. As a start study comparisons of FTS-querie performance on large datasets between MongoDB and MySQL.
  • Problem. Queries may return up to 1000 articles. This causes slow turn arounds (network) and undesirable client-overloading (to long a list of results in the UI).
  • Tentative Solutions
    • Endless scroling. Retrieve more data when required by the frontend. The user scrolls down, available data are (nearly) consumed. The frontend asks for more data. And so on. The technology is complicated and available frontend libraries are platform dependent (Android, IOS, ..). The million dollar question. Is there a simple solution making the effort worth the trouble? Check out if there is a multi platform JQuery-plugin to easily implement endless scrolling triggering and result rendering in the frontend. Check out the costs of adapting the backend.

Some non-UI ideas

  • Subscribe to email news-digest and/or SMS-alert
  • TrenTops: Add a trendy topic each day and keep repeating a newly introduced topic (examples: Brexit, Migration, Cannabis, ...)
  • Checkout Google-API's for additional news (News, Youtube)
  • Start mining Twitter
  • Add topical categorization (Econfin, Traveleisure, ArtCult, EduScience, etc.). How? Make FBR-fastText-predictor real-time.


  • https://medium.com/@richardnfreed/the-tech-industrys-psychological-war-on-kids-c452870464ce

API and current UI

  • De API-url bestaat dus uit: Taal (twee letters, ISO_639-1), vanaf tijd, totaan_tijd en een zoekterm. Tijd is altijd in UTC, conform ISO_8601. De zoekterm is optioneel. Het woordje none betekent: er is geen zoekterm.

Het ligt voor de hand om de API-onderdelen in één UI interactie te kunnen instellen. Nu kies je taal via het menu. Standaard (home page) krijg je het al het nieuws dat in het laatste uur is verzameld.

Als je wilt zoeken met een zoekterm dan ga je naar de 'zoeken'-pagina waar je (1) de term kunt invullen en (2) een aantal uren kunt invullen. Met dat aantal uren geef je aan hoe ver je `terug wilt zoeken`. De eindtijd is per definitie UTC-nu. De vanaf tijd is UTC-nu minus het aantal ingevulde uren.

  • make NR a one-page application? Modelled on scrolling through the FB-timeline (get only more news-items from the server when the user scrolls down (deeper into the past) and more items have to appear on the screen)
( by kred to all at 2018-08-29 23:38:09 in Language )

International money transfers? Worldremit beats your bank!

Domains, Hosting? Go Versio!

[Login to add a comment]