Carafe.FM Feedback, Bugs, Feature requests

[Russell Watson]

Hi Jeremiah,

maybe this is a place we can pass Feedback to you about Carafe.FM?

MrWatson

Improvement: UX confusing when search finds nothing

Hi Jeremiah,

I'm still goggling at Carafe ... and loving every minute of it! In general fantastic job on the UX of the whole app! Congrats!

One thing is confusing ... when you search for something and nothing is found there is no feedback ... I then made the mistake of thinking the two little arrows to the right of the search box are for navigating the search term ... but clicking them doesn't work ... and then I realised, that they are for sorting ...

Solution idea: Visual feedback

It would be great if there was some kind of visual feedback to let you know that nothing has been found.

Maybe a (very) quick and dirty fix could simply be a conditional format on the search box -> goes red when error 401 is active. (See image)

Thanks

MrWatson

P.S. Have you considered hosting the Carafe.FM FileMaker files on GitHub?

You have your other Carafe-code on GitHub, why not the FileMaker files, too?

OK, so they are binary files, but on GitHub we could leverage the Issue-tracking tools, and make use of pull requests, etc.?

[Russell Watson]

OK, so FMForums merges multiple posts into one ... good to know.

Bug: object missing

I noticed the sort buttons cause an error if you have pause-on-error set. Doesn't effect the UX, but good to clean up

 MrWatson

Feature Request: Support for Deploy/Update flow

Currently you can only copy the entire script out of Carafe.

Will you be considering an option to copy just the script steps, so that we can update an existing script (so as not to break calls to it)?

Like that I can develop my source code bit by bit and continually redeploy the source code out of Carafe without breaking my script or having to fiddle around pasting a script and then copying the steps over to the old script.

THANKS for a fantastic tool (watched Carafe part 2 in the meantime ... fantastic aims!)

❤️

MrWatson

[dual_mon]

Hey, thanks very much for the kind words and enthusiasm. We are getting ready to release 3.1.0 this week, which includes some bug fixes and enhancements. I'm going to see if we can fit in any or all of these suggestions. If not, I'll let you know what's going on at the very least. Thanks for the very detailed feedback.

[Russell Watson]

Great News!

I've seen a recent Carafe-entry in the FileMaker Forum ... so I guess things are beginning to pick up!

 

Another Feedback:

I've noticed that the final script that gets pasted into your target solution does not document the Bundle author:

# ====================================================================================================
# PURPOSE:
# Loads Carafe C3 v2.1.0 into a Web Viewer.
#  
# DEPENDENCIES:
# Must run in the context of a layout containing a Web Viewer named to match the configured value below
#  
# HISTORY:
# Generated 4/27/2020 by Carafe v3.0.3
#  
# PARAMETER TEMPLATE:
# JSONSetElement( $parameter
 ; [ "jsonData" ; $jsonData ; JSONString ]
)
#  
# ====================================================================================================

 

I find that a shame.

I think it would be fair to the original authors to reference them in the comment, maybe something like this:

:
# DEPENDENCIES:
# Must run in the context of a layout containing a Web Viewer named to match the configured value below
#  
# CREATOR:
# Jesse LaVere
#  
# HISTORY:
# Generated 4/27/2020 by Carafe v3.0.3
#  
:

 

Thanks for everything!

MrWatson

[Russell Watson]

Feature Request: Script documentation with Links

This is an extension of my last post, in which I suggested mentioning the author/creator of the bundle in the script comment.

This idea builds on that with the suggestion of adding some LINKS in the script comment.

Below are some example links for the Carafe Leaflet v2.1.0 Bundle:

# ====================================================================================================
# PURPOSE:
# Loads Carafe Leaflet v2.1.0 into a Web Viewer.
#  
# DEPENDENCIES:
# Must run in the context of a layout containing a Web Viewer named to match the configured value below
#  
# HISTORY:
# Generated 4/23/2020 by Carafe v3.0.3
#  
# PARAMETER TEMPLATE:
# JSONSetElement( $parameter
 ; [ "mapData" ; $mapData ; JSONString ]
)
#  
# LINKS:
# Made with: https://carafe.fm
# Created by: https://carafe.fm/author/soliant/
# View Bundle online: https://carafe.fm/bundle/leaflet-soliant/
# View Bundle in Carafe: fmp://$/Carafe.fmp12?script=ViewBundle&$id=256824A3-2692-40B9-A5AF-4FE42DFDF4D0
# Redeploy Bundle from Carafe: fmp://$/Carafe.fmp12?script=RedeployBundle&$id=256824A3-2692-40B9-A5AF-4FE42DFDF4D0
#  
# ====================================================================================================

 

You can see that the list contains

• 'normal' links
  • to the Carafe website,
  • to the Carafe author page and
  • to the online bundle documentation,
• as well as some special fmp-url 'action' links:
  • action link to view the bundle in (the open) Carafe file
  • action link to trigger a redeployment of the bundle in (the open) Carafe file

 

Links in the bundle's comment are certainly helpful - even if the user has to copy the URLs out by hand and manually type them into the browser, they are still useful.

• so that the code does not get severed from the Carafe tool.
• so the user can quickly find documentation

However, if the user installs fmAutoMate (https://www.fmworkmate.com/fmautomate) - a (mac-only) tool - from me & using the MBS plugin - aiming to turn the script workspace more into an IDE - it becomes as easy as just clicking the links - or even just pressing ctrl+cmd+U.

Here is a proof-of-concept video fmAutoMate Towards an IDE with Carafe (worth watching!)

 

The action links

I have hacked together two scripts in my version of Carafe

• ViewBundle - to display a bundle
• RedeployBundle - to trigger the redeployment (that is update) process

as a proof-of-concept of the method. (These I can provide to you, so that you can code them 'properly', if you wish)

 

Let me know what you think!

Happy FileMaking!

 

MrWatson

 

 

 

 

 

 

 

[dual_mon]

2 hours ago, Russell Watson said:

# LINKS:
# Made with: https://carafe.fm
# Created by: https://carafe.fm/author/soliant/
# View Bundle online: https://carafe.fm/bundle/leaflet-soliant/
# View Bundle in Carafe: fmp://$/Carafe.fmp12?script=ViewBundle&$id=256824A3-2692-40B9-A5AF-4FE42DFDF4D0
# Redeploy Bundle from Carafe: fmp://$/Carafe.fmp12?script=RedeployBundle&$id=256824A3-2692-40B9-A5AF-4FE42DFDF4D0

Very cool idea. Simple to add some URLs as you suggest, so I'll include some in 3.1.0

As far as the specific suggestions you've made, I'll end up doing a few things slightly differently. I'll comment on them in order.

• Referencing the home page for Carafe makes sense
• The "author" in Workdpress differs from the bundle creator. The author is effectively the publisher entity, and (as in fact is the case) can represent multiple creators. So I think this isn't a huge advantage over the prior and next links. I'll probably leave this out.
• Bundle "homepage" is a new feature of the v3 bundle format. It is already a opt-in feature of the draft-02 bundle schema to provide a canonical url. These will tend to be on carafe.fm, but in theory a publisher could put in different bundle homepage. This is a very good idea. I'm adding this to 3.1.0
• The idea of callback hooks into Carafe is an interesting idea. I am inclined to make it an opt-in generalized hooks feature which the end user can define in the Carafe file. Similar to how we handle advanced deployment where you need to specify a table and field name in the deployment screen, and those values get added into the deployed script. This idea could allow people to mod the solutions without having to bake the use case(s) into the core file. For example, if you specified an fmp url targeting "CarafeHooks.fmp12" to receive the fmp url, and then do whatever kind of custom mods you like in a separate interface file, it would be more portable when you upgrade versions of the core file. Let me see if I can incorporate this into 3.1.0

 

[Russell Watson]

8 hours ago, dual_mon said:

Very cool idea. Simple to add some URLs as you suggest, so I'll include some in 3.1.0

Great!

 

8 hours ago, dual_mon said:

The idea of callback hooks into Carafe is an interesting idea. I am inclined to make it an opt-in generalized hooks feature which the end user can define in the Carafe file. Similar to how we handle advanced deployment where you need to specify a table and field name in the deployment screen, and those values get added into the deployed script. This idea could allow people to mod the solutions without having to bake the use case(s) into the core file. For example, if you specified an fmp url targeting "CarafeHooks.fmp12" to receive the fmp url, and then do whatever kind of custom mods you like in a separate interface file, it would be more portable when you upgrade versions of the core file. Let me see if I can incorporate this into 3.1.0

My thoughts: While a generalised doc-hooks feature would make it possible to integrate the bundle into some other work flows (like what though?) I feel the two workflows

- Show bundle in Carafe, and 

- Update bundle from Carafe (i.e. Script *steps*)

would be better if they are ‚baked in‘.

I.e. Updating of a bundle should be as easy as the initial deployment of a bundle - just one click - with no further settings necessary, because all of the original settings are remembered in the URL.

This would make it possible to keep bundle development 100% separate (in carafe) and simply redeploy to get the latest code (like pulling latest  code from github)

Your ball 🙂

 

have fun!

[dual_mon]

23 hours ago, Russell Watson said:

would be better if they are ‚baked in‘.

I'm not sure I agree here. Perhaps an API interface file could ship with some example scripts, but if this type of thing is baked into the core Carafe.fmp12 file, you'd either have to live with exactly one set of use cases, or always have to port your mods over to it any time the core file is updated. On the other hand, if you maintain a separate API file, you would be much more likely to be able to retain specialized use cases like the automation integration you are going for without skipping updates to the core file.

[Russell Watson]

I'll go with you on this one ... You've been thinking about all this stuff for over a year - and doing a VERY good job of it! ... I'm just looking at it from my own perspective, and don't have a feel for the bigger picture.

Do what you do well!