Re: UI/UX implementation for suggestions

[Rik]

On 04/27/2018 07:33 AM, address@hidden wrote:

Subject:

Re: Proceeding with the GSoC Project

From:

Nicholas Jankowski <address@hidden>

Date:

04/27/2018 06:20 AM

To:

Sudeepam Pandey <address@hidden>

CC:

Nicholas Jankowski <address@hidden>, Doug Stewart <address@hidden>, octave-maintainers <address@hidden>

List-Post:

<mailto:address@hidden>

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden> <address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

multipart/alternative; boundary="001a114d73fa99cdf0056ad4603b"

Message:

1

On Fri, Apr 27, 2018, 08:43 Sudeepam Pandey <address@hidden> wrote:

On Fri, Apr 27, 2018 at 5:05 PM, Nicholas Jankowski <address@hidden> wrote:

It seems you have several separable programming tasks. These need to be blocked out and addressed independently. That includes and analysis of options and alternatives after a review of what's been done before by others.

 1 - implement a suggestion feature within octave, independent of algorithm, and a framework for connecting to it. I would consider this a near term objective, lest it become a last minute kludge. It would be testable with even the most trivial of suggestion algorithms 

2 - implement a suggestion algorithm for 'online' suggestions, that needs to be delay free to the user. It may make sense to have both high confidence and lower confidence a approaches to this, bit I'm not yet convinced you've researched to options including what's already been done.

3 - implement any offline suggestion algorithm components that will aid 2. This may or may not be separable from 2. If this requires maintainer action, that will need a reasonable framework.

4. Document. Especially if this will require later manual actions on each new octave release. updates

I am really sorry but I don't understand some of these things. Please clear these up for me.

1) What exactly do you mean by a suggestion feature "independent of an algorithm" and "testable with even the most trivial of suggestion algorithms"?

2) What do you mean by "online and offline suggestions"?

1 - how the feature presents itself to the user and hooks into octave is separate from what happens behind the scenes to generate the words to suggest.  

If we implemented a  pop-up dialog box where the user could select the intended command, that could be tested without having any neural network or nearest neighbor searching going on in the background. It could be tested with a simple 10 word look up table just to show that the functionality is correct. Later the actual suggestion feature should be some separate, independent function that is separately testable. But having it be independent will involve defining the interface to that piece such that any algorithm should be able to provide word suggestions to it. If a better algorithm comes along later, someone could implement it without having to change the code for actually hooking into octave.

Sudeepam,

For better or worse, you have a project which is generating a lot of interest.  First, I agree with the others that you should separate the implementation of a suggestion algorithm, from the interface to the user.  Logically, they are different and it allows a "divide and conquer" approach to engineering.  It also helps future proof the system.  If the actual suggestion algorithm is implemented through a stable API then as new techniques come along we can improve the quality of the suggestions without ever disturbing the user.

Second, I think you need to spend some time up front thinking about the user interface (UI) and user experience (UX).  Unfortunately, this is an area where there will be a lot of opinions.  Nevertheless, you eventually need to have user's like how the feature is presented, or they will disable it and it will eventually atrophy and be removed from Octave.

Here are some questions to help motivate discussion.

1) Should keywords be included?  The script I sent earlier was only for functions, but I personally would like a typo like "fndfunction" corrected to "endfunction"
2) Should user variables be included?  If I define a variable "myvar" and then type "myver", what should happen?
3) Should internal functions ever be offered as suggestions?  Internal functions start with the prefix "__".  They are not meant to be called directly, so is there any reason to make them a suggestion?  If I type "betaind", I should be reminded that I probably want "betainc", but I don't think I should be offered the choice "__betainc__"
4) What about deprecated functions?  Should they ever be offered as a suggestion?  You could just remove them from the suggestion list, or maybe you want to go a step further and recommend their replacement?
5) How are you going to offer alternatives and allow them to select an alternative?  Remember that Octave has both a CLI and a GUI so you may need two solutions.

--Rik