Hi Dmitry,
Since Gayan is in support now, I will continue to work on this.
The doc attached, contains the items completed by Gayan so far.
I will be able to do a demo on next Monday with the completed items. And we
will be able to ship the completed feature for M6.
Thanks
Manisha
On Fri, Aug
Excellent news, Manisha!
I am in Colombo starting Tue, Sept 9 - so demos and sync-ups will be quite
easy. :)
Dmitry
On Tue, Sep 2, 2014 at 11:46 PM, Manisha Gayathri mani...@wso2.com wrote:
Hi Dmitry,
Since Gayan is in support now, I will continue to work on this.
The doc attached,
Hi Dmitry,
Please see my comments inline.
On Thu, Aug 14, 2014 at 12:17 PM, Dmitry Sotnikov dmi...@wso2.com wrote:
Gayan and Dimuthu,
From my perspective, one-off UX exceptions are bad, because they make the
UI inconsistent.
There are two types of messages:
A. High-level external
Yes, some sort of PoC would be good. I am not sure what you mean by showing
the Type B messages on the page - so would be great to see it in action or
at least on mockups...
On Aug 14, 2014 8:02 PM, Dimuthu Leelarathne dimut...@wso2.com wrote:
Hi Dmitry,
Please see my comments inline.
On
Hi Dmitry,
I have scheduled a demo o Monday. I will do a sample implementation of the
two scenarios and give a demo to you on Monday.
GayanD
On Fri, Aug 15, 2014 at 1:05 AM, Dmitry Sotnikov dmi...@wso2.com wrote:
Yes, some sort of PoC would be good. I am not sure what you mean by
showing
Hi Dimuthu / Dmitry,
IMHO it is not good to use the wall to show on going events. It is more
meant to show an action which is triggered by a user or an action triggered
by the app factory system.
Currently we have build and deployment events which takes some time to
complete. While I agree the
Hi Gayan,
According to our offline discussion, then lets do this.
1 - Identify and list all actions that we want to give
started-inprogress-ended messages
2 - Identify on which sections we are going to give feedback - spinning
icon with messages
If all of us agree, proceed.
thanks,
dimuthu
Hi Dimuthu,
Following are a set of actions that we want to give
started-inprogress-ended messages and places where we would put the
spinning wheel and messages.
1) Application Creation - User home near the application thumbnail (This is
already implemented)
2) Application Upload - Application
Hi Dimuthu,
I tried a sample implementation to show the implementation on the
application wall. This was done by looking at the content of the message.
It was successful. But this may not be ideal since for different kind of
start-inprogress-ended messages we may need to have different logic.
Hi all,
We have identified that the events in the doc attached herewith are the
events which are triggered within each page. While some of them are already
published, some of them needs to be published to the social component in
order to enhance the user experience and collaboration. While doing
Gayan,
A few items seem to be missing:
- Issue tracker events,
- Lifecycle: production URL assignment, ToDo checkbox selected/cleared.
Also, are we adding additional noise-reduction filter so user by default
sees more events related to his/her activity and smaller number of events
related
Hi Gayan,
See my comment in-line.
On Tue, Aug 12, 2014 at 1:54 PM, Gayan Dhanushka gay...@wso2.com wrote:
Hi all,
We have identified that the events in the doc attached herewith are the
events which are triggered within each page. While some of them are already
published, some of them
Hi Dmitry,
Thanks for pointing things out. IMO that would be phase two Dmitry. As soon
as I complete publishing all the relevant events I will look to accommodate
the noise-reduction filter as well. WDYT of the suggestion made by Udara in
the above reply? I think that is a valid comment as well.
Gayan,
Indeed, looks like Udara and I are thinking along the same lines. :) This
is more than just a build. E.g. when I am creating an application, there
are a lot of things that happen (borrowing from your list):
1. application creation started
2. initial git repo creation
3. jenkins
Hi all,
Personalized app-wall can be achieved by the way we publish activities to
social component. In current implementation, we publish activities to two
contexts called 'foo-user' and 'bar-app' which is rendered in wall as 'foo
user wall' and 'bar app wall'. We can introduce another context
Hi Manjula,
Thanks for the input. I will try to utilize the above mentioned method in
the second phase when trying to make the app wall more personalized.
Regards
GayanD
On Tue, Aug 12, 2014 at 5:56 PM, Manjula Rathnayake manju...@wso2.com
wrote:
Hi all,
Personalized app-wall can be
Hi,
There can be several methods, one being subscription management. However
since master branch is shared by all it would be interesting to know
whether a build was triggered on it by all. However even in the first phase
we must filter out activities happening on the fork repos. I think the
Hi Gayan,
We'll also need to consider about the failure events while tracking the
progress.
eg. Deployment failure should stop the progress of the deployment event.
So we'll have to keep track on start, failure and stop status of a
particular event.
Other concern is assigning UUID's for
Hi Anuruddha / Dimuthu,
The more global this ID is for all the events makes it more consistent.
Otherwise we'll have to render these messages according to different
parameters which are there in each message. Having said that we need to
figure out a common way of doing this. Doing this by looking
19 matches
Mail list logo