Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDAGU-0003Qp-Is for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 12:49:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bDAGU-00076c-5R for pgadmin-hackers@arkaria.postgresql.org; Wed, 15 Jun 2016 12:49:50 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bDAGG-0006s2-Cq for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 12:49:36 +0000 Received: from mail-io0-x234.google.com ([2607:f8b0:4001:c06::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bDAGD-0003aV-9j for pgadmin-hackers@postgresql.org; Wed, 15 Jun 2016 12:49:35 +0000 Received: by mail-io0-x234.google.com with SMTP id f30so13274820ioj.2 for ; Wed, 15 Jun 2016 05:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Y0QgYfhRpXgzj54hiaVCjWK6k5ZA/Y8PTp32f8N8Pk=; b=MsNiLLJUnG0RuTDfQm6wQG0N1DED7S34vnLF/04D5T+t6fu+rtc4rr5jPUOrrs9Gyw Hz1M8wbZF1ISuxATmbRRqBjcppA8U0W5p9udgYGYn8A63ER/zEGxNaoHLhgEm7aG8JZD pzOIEuhsKJ57RJzRo5TS5JHn+F6rn2l0MuQB9FMQldBVbGwH1AuWfsBUUjoqY1MyN4GQ dZFpJ3fyQOmEW6wVlMPrcZGuKKcLPiS+u2zjGpZbr8u3VlQ2DZJEraz8Y9ZpXLJ2ohc6 FmBtV3rPafps8Or1BAYsYodkMjljWFSxRyrqCv15djs/aDVyjbB08qBmCy39Z3W4LEFU C1lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6Y0QgYfhRpXgzj54hiaVCjWK6k5ZA/Y8PTp32f8N8Pk=; b=O+YYA8coskYsPqVaa/G/T/1vpQmQhoFfMpiVMb6RvRFpelQPNxuPXYSv5F74DhUtPv 4lzvmzEC5glQnLFnwvXMUB7VTaHT9MdlfPGXeQXJE7Mz/th9HsRDJtDZwPevBpKeKe6r raXa1ku41F/dKZysshmqv3A953vFgnn5ichGsxjs/978THgOAKpNwmZmtzV675MjyTfc vrwtf22l/urcKtIvwMLeJhlQaGZPk/i2bSUd4ZxDNb/SIn/qaDGJThzn++2St6jFJTry LlRJuPDs/o5asfSlbIZnlGsMOMluXHWnC9KK8x8PxaYbjg0RlH+LS2SSh4t8MxIiYS7A VQsg== X-Gm-Message-State: ALyK8tIM4F872f1ZkWG+318k+Ayh55T6T4pjMlNHfTBdKozyJrK9EK7KldpW/8l222kdZ1e7R6RDQ2aUfLDZDCEQ X-Received: by 10.107.32.148 with SMTP id g142mr37959618iog.117.1465994971998; Wed, 15 Jun 2016 05:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.217 with HTTP; Wed, 15 Jun 2016 05:49:12 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Wed, 15 Jun 2016 18:19:12 +0530 Message-ID: Subject: Re: Regarding issue 1241 To: Dave Page Cc: Harshal Dhumal , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a1141b05e8c99030535508dc4 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a1141b05e8c99030535508dc4 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 1:59 PM, Dave Page wrote: > > > On Tue, May 31, 2016 at 8:53 PM, Harshal Dhumal < > harshal.dhumal@enterprisedb.com> wrote: > >> Hi Dave, >> >> Regarding Issue 1241 : >> >> We have added header section for parameter tab deliberately so that we >> can force user to select parameter name (and therefore parameter's data >> type) before adding new row. This is required because behavior of second >> cell (Value cell) is dependent on what parameter name user has selected in >> first cell (Name cell). See attached screen-shot. >> >> For example: >> 1. If user selects parameter 'array_nulls' then value for this should be >> either true or false (and hence switch cell). >> 2. If user selects parameter 'cpu_index_tuple_cost' then value for this >> should be Integer (and hence Integer cell). >> >> Without the custom header (and forcing user to select parameter) we >> cannot decide what type of cell we need in second column. >> >> Let me know your opinion on this. >> > > We need to figure out a way to fix it. Our difficulties encountered > writing code should not dictate usability compromises. > In this case, something that needs some thought and maybe some tricky code > has caused us to create an inconsistent UI workflow to side-step the > problem, which is not appropriate as it leads to a poor look and feel and > potentially confusion for the user. > Agree - we should handle these cases gracefully. We need to over come the limitation by brain storming, which we already started offline. :-) To be honest - it is a time consuming work, and there is no quick fix for this. We can handle it as one case for each change instead of targeting all UI changes as one whole problem. And, we can utilize the same time to fix a lot more cases in beta 2. I can ask Harshal to find out all possible places, where the similar changes are required, and create a separate case for each (though - not without your agreement). -- Thanks & Regards, Ashesh Vashi > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > --001a1141b05e8c99030535508dc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 2, 2016 at 1:59 PM, Dave Page <dpage@pgadmin.org> wr= ote:

On Tue, May 31, 2016 at 8:53 = PM, Harshal Dhumal <harshal.dhumal@enterprisedb.com><= /span> wrote:
Hi Dave,
<= br>Regarding Issue 1241:

We have added header section for par= ameter tab deliberately so that we can force user to select parameter name = (and therefore parameter's data type) before adding new row. This is re= quired because behavior of second cell (Value cell) is dependent on what pa= rameter name user has selected in first cell (Name cell). See attached scre= en-shot.

For example:
1. If user selects parameter 'array_nul= ls' then value for this should be either true or false (and hence switc= h cell).
2. If user selects parameter 'cpu_index_tuple_cost' the= n value for this should be Integer (and hence Integer cell).

Without= the custom header (and forcing user to select parameter) we cannot decide = what type of cell we need in second column.

Let me know your opinion= on this.

We need to= figure out a way to fix it. Our difficulties encountered writing code shou= ld not dictate usability compromises.=C2=A0
In this case, something that needs some thought and = maybe some tricky code has caused us to create an inconsistent UI workflow = to side-step the problem, which is not appropriate as it leads to a poor lo= ok and feel and potentially confusion for the user.
=
Agree - we should handle these cases gracefully.
We need to over come the limitation by brain storming, which we already s= tarted offline. :-)

To be honest - it is a ti= me consuming work, and there is no quick fix for this.
We c= an handle it as one case for each change instead of targeting all UI change= s as one whole problem.
And, we can utilize the same time to = fix a lot more cases in beta 2.

I can ask Hars= hal to find out all possible places, where the similar changes are required= , and create a separate case for each (though - not without your agreement)= .

--
Thanks & Regards,
Ash= esh Vashi
<= br>
=
--
Dave Page
Blog:= http://pgsnake.b= logspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com=
The Enterprise PostgreSQL Company

--001a1141b05e8c99030535508dc4--